Cron Expression Explainer

The rule that catches everybody

When both the day-of-month and the day-of-week field are restricted, cron fires when either one matches - not when both do. So 0 0 1 * 1 does not mean the first of the month when it falls on a Monday. It means the first of the month, and also every Monday, which is roughly five times as often as most people intend. When one of the two fields is a star, the other simply applies and the surprise disappears.

This tool spells the rule out in the explanation rather than leaving it implicit, and the next-run table makes it visible: you can see the extra fires in the dates. It is the single commonest cron bug and it usually reaches production because the expression looks correct.

Next runs, in a real timezone

Cron fields are wall-clock times in whatever zone the daemon is running in, which is why a job that should run at 02:00 IST is often scheduled for 20:30 UTC by hand and then quietly wrong after a clock change. Pick a zone here and the next ten runs are computed against that zone's actual daylight-saving rules, with the equivalent UTC instant beside each one.

The calculation walks the calendar field by field rather than testing every minute, so a once-a-year expression answers as quickly as a once-a-minute one. If an expression cannot fire at all - 0 0 30 2 * asks for the thirtieth of February - it says so, which is more useful than an empty table.

• Five-field Unix syntax, or six with a leading seconds field
• Ranges, steps, lists, and month and weekday names
• Macros: @yearly, @monthly, @weekly, @daily, @hourly
• Both 0 and 7 accepted for Sunday

What it will not do

It covers standard Unix, or Vixie, cron. Quartz and Spring add L for last, W for nearest weekday, and the nth-weekday hash, and those are rejected with a message naming them rather than approximated. Ignoring a modifier we do not understand would produce a schedule that looks right and is not, which on a scheduling tool is the worst possible failure.

It also cannot know your server's zone, its clock skew, or whether the daemon was running - so these are the times the expression describes, not a promise that a job fired. And @reboot is not a schedule at all: it fires once at startup, so there is nothing to list.