How it works
- 01
Build or paste
Click the hour and weekday grids to build an expression, or paste one you already have.
- 02
Read it back
Each field is expanded to the values it really matches, and the whole thing is described in a sentence.
- 03
Check the next runs
Six upcoming runs in the time zone you pick, so a mistake shows up before it ships.
The traps in cron syntax
Two fields catch almost everyone. Day of month and day of week are ORed, not ANDed. An expression with both set runs on either condition, so 0 0 13 * 5 fires on the 13th of every month and on every Friday. It is not Friday the 13th. Leave one of them as a star unless you want both.
A step counts from the start of its range rather than from zero. In the hour field, */7 means 0, 7, 14 and 21, then a five-hour gap over midnight. It is not a clean seven-hour cycle. The expansion column shows the values, which is the quickest way to catch this.
Time zones are the other repeat offender. Most cron daemons run in the server time zone. A job set for 02:30 then runs twice, or not at all, on the night the clocks change. If it must run exactly once, put it outside the 01:00 to 03:00 window, or run the daemon in UTC.
- Dialects
- Standard 5-field crontab, 6-field with seconds, and Quartz or Spring.
- Special strings
- @hourly, @daily, @weekly, @monthly, @yearly and @reboot are all recognised.
- Time zones
- Next runs in any IANA zone, with daylight saving handled properly.
- Validation
- Values out of range, backwards ranges and dates like 31 February are refused.