Cron Translator

A cron expression is five values in a row that decide when a scheduled job runs, and almost nobody can read one at a glance. This turns one into a sentence, then proves the sentence by listing the next five times the job would actually fire.

What it does

You type a schedule into one box and get two answers back. The first is a plain sentence describing what you just wrote. The second is a list of the next five moments it would run, as real dates and times in your own timezone.

Both update on every keystroke, so a half-finished expression is already telling you something. If it cannot be read, the sentence turns red and names the piece it choked on, or says it wanted five fields and counted something else. Four presets fill the box with the common schedules.

The five values, in order, are the minute, the hour, the day of the month, the month, and the day of the week. Each one accepts a single number, a list, a range, a range with a step, or a star meaning every value.

Why it exists

I can write the easy schedules from memory and I second-guess every one that is not. The risk is never an expression that looks wrong, because you fix those immediately. It is the one that looks right. A job meant to run hourly that quietly runs every minute costs nothing until something fills up.

So the sentence is the sanity check and the run list is the evidence. If they disagree with what you meant, you find out in the browser rather than in a log a week later.

The rule that catches almost everyone

If you set both a day of the month and a day of the week, cron runs when either one matches, not both. Ask for the first of the month and also Monday, and you get every first plus every Monday, which is far more often than most people expect. Nearly everybody reads that as an and.

The tool follows the real behaviour rather than the intuitive one, so the run list shows you the surprise instead of smoothing it over. That rule alone is most of the reason a preview beats a description.

How the preview is built

There is no clever mathematics behind the next five runs. It starts at the next whole minute and steps forward a minute at a time, testing each against the schedule until it has five hits. Worst case is a little over half a million checks, which a browser finishes before your finger is off the key.

It gives up after 366 days. That limit is the useful part: an expression that can never fire, like the thirty-first of February, says so instead of hanging forever looking for a date that does not exist.

What it will not do

• Named days and months. Only numbers. Spelling a weekday out is rejected rather than guessed at.
• Shorthand macros. The daily, weekly and reboot style keywords are not supported.
• Seconds. Strictly five fields, so the six-field style used by some job schedulers will be refused.
• The vendor extensions. Last-day-of-month, nearest-weekday and nth-weekday markers are not standard cron and are not handled.

Refusing is deliberate. A translator that silently ignores a piece it does not understand is worse than useless, because you walk away confident about a schedule it never actually read.

One honest limitation: the preview uses the timezone of the machine you are sitting at, and real cron usually runs in the server's, often UTC. Treat the run list as a check on the shape of the schedule, then apply the offset yourself.

Built with

One page, no build step, no server, nothing stored. Everything happens in the browser, so the expression you are testing never leaves your machine.