Cron Expression Explainer

What this explainer reads, and what it does not check

It splits your expression on whitespace, insists on exactly five parts, and describes each part on its own line. That is the whole of it. It is a field-by-field translator, and understanding its limits is most of what you need to use it safely.

The most important limit comes first, because it decides whether the green status light means anything.

“OK” means five fields, not a valid schedule

The status turns green as soon as there are five whitespace-separated parts. It performs no range checking whatsoever. Measured, every one of these reports OK in green:

• 99 99 99 99 99, described as “Minute: 99, Hour: 99” and so on, although minutes stop at 59 and hours at 23.
• x y z p q, described as “Minute: x, Hour: y”. Letters are passed straight through.
• 0 0 32 * *, a 32nd day of the month.
• 0 0 * 13 *, a thirteenth month.
• 0 0 * * 8, an eighth day of the week.

So a green OK on this page tells you your expression has the right shape. It tells you nothing about whether a scheduler will accept it or whether it will ever fire. Read the green light as “five fields found” and nothing more.

What it does reject is the wrong number of fields. An empty box, four fields, six fields, and the shorthand forms @daily and @reboot all produce “Need exactly 5 fields” in red. That rules out two common things: the six-field style used by Quartz and Spring, where the first field is seconds, and the @ shortcuts that Vixie cron supports. For reference, @daily is the same schedule as 0 0 * * *, @hourly is 0 * * * *, @weekly is 0 0 * * 0, @monthly is 0 0 1 * * and @yearly is 0 0 1 1 *. Any of those can be typed in longhand and this page will read it.

The day-of-month and day-of-week trap, which this page does not warn you about

This is the single most expensive misreading in cron, and the output here does nothing to prevent it. Given 0 0 1 * 1 the page prints two independent lines, “Day of month: 1” and “Day of week: Mon (1)”, and almost everyone reads that as the first of the month, when it is a Monday.

It is the opposite. When both of those fields are restricted, cron fires when either matches. The POSIX specification puts it this way: “if either the month or day of month is specified as an element or list, and the day of week is also specified as an element or list, then any day matching either the month and day of month, or the day of week, shall be matched.” The Linux crontab manual gives the worked example: “If both fields are restricted (i.e., do not contain the "*" character), the command will be run when either field matches the current time. For example, "30 4 1,15 * 5" would cause a command to be run at 4:30 am on the 1st and 15th of each month, plus every Friday.”

So 0 0 1 * 1 runs on the first of every month and on every Monday, which is roughly five times a month rather than once or twice a year. If you want a genuine “first Monday”, standard cron cannot express it in one line. The usual answer is to schedule 0 0 1-7 * 1 and have the command itself check the date, or use a scheduler with extended syntax.

Where the field-by-field descriptions go wrong

Four cases where the wording is misleading rather than merely terse. All measured on this page:

• A step on a range is garbled. 1-5/2 is described as “every 2 starting 1-5”. It actually means every second minute within the range 1 to 5, so minutes 1, 3 and 5. The description reads as though the range were a starting point.
• A negative number is read as a range. -1 is described as “from -1”, because the hyphen is taken for a range separator before anything checks whether the value is a number.
• Nonsense steps are repeated back as fact. */0 becomes “every 0”, and 0-59/120 becomes “every 120 starting 0-59”, a step larger than the field it applies to.
• Three-letter names are not translated. 0 0 * JAN MON comes back as “Month: JAN” and “Day of week: MON”, with no month or weekday name attached, in either case. Real cron does accept these: the Linux manual says “Names can also be used for the 'month' and 'day of week' fields. Use the first three letters of the particular day or month (case does not matter). Ranges and lists of names are allowed.” So a valid expression gets a less useful description than a numeric one.

The numeric forms it handles well. A plain number, a comma list such as 1,15, a simple */5 step and a bare * are all described accurately, and both 0 and 7 in the day-of-week field are correctly named as Sunday, which is a detail many explainers get wrong.

Extended syntax is echoed back without meaning

Several schedulers add characters that classic cron has no idea about, and because this page does not validate, they pass straight through looking as though they were understood. Measured, 0 0 L * * yields “Day of month: L”, 0 0 * * 5#3 yields “Day of week: 5#3”, and Jenkins-style H/15 yields “every 15 starting H”.

In the schedulers that support them, L means the last day, 5#3 means the third Friday of the month, and H means a value spread out by the scheduler to avoid everything firing at once. None of that is explained here, and none of it is valid in classic cron. The echo is not a translation.

Whitespace, at least, is forgiving. Leading and trailing spaces are ignored and runs of several spaces between fields are treated as one separator, so an expression copied out of a crontab with odd alignment still reads correctly.

What this tool deliberately does not do

• It does not validate ranges, so minute 99, month 13 and weekday 8 are all reported as OK.
• It does not tell you when the job will next run. There is no next-fire time anywhere on the page, and that is the question most people arrive with.
• It does not warn about the either-or rule between day of month and day of week, which is the most common way a cron line surprises its author.
• It does not accept six-field expressions, so Quartz and Spring schedules with a seconds field have to have that field removed first.
• It does not accept the @ shortcuts such as @daily or @reboot.
• It does not understand three-letter month or weekday names, even though cron does.
• It knows nothing about time zones. A cron line fires in whatever zone the scheduler runs in, and that is not shown here. To work out what a given hour means elsewhere, use Time Zone Converter.
• Nothing is uploaded. The parsing runs in your browser and your expression never leaves your device.

Sources

• The either-or rule for day of month and day of week, and the definition of the five fields: The Open Group Base Specifications, crontab. pubs.opengroup.org
• The same rule with a worked example, three-letter names, step values and the @ shortcuts: crontab(5), Linux manual pages. man7.org/linux/man-pages/man5/crontab.5.html

Every behaviour and every value on this page was measured against this tool as it is published, in a browser, on 14 October 2026. Where the page says what the tool does not do, that is a statement about this tool, not about cron.