Cron Expression Explainer - Plain English and the Next 10 Run Times

A standard crontab entry has five fields separated by spaces: minute (0 to 59), hour (0 to 23), day of month (1 to 31), month (1 to 12 or JAN to DEC) and day of week (0 to 7, where 0 and 7 are both Sunday, or SUN to SAT). A field can hold a list (1,15), a range (1-5), a star for every value, and a step: */5 means every fifth value, and 1-10/2 means 1, 3, 5, 7 and 9. A step must follow a star or a range: cronie rejects a step after a single number, as in 5/15. The macros @yearly, @annually, @monthly, @weekly, @daily, @midnight and @hourly stand for ready-made schedules (cronie reads their names in lower case only, so @DAILY is an error), and @reboot means once after the machine boots, when the cron service starts. The plain English text is produced by this tool's own code from the parsed fields. Cron looks at its entries once a minute, so the smallest step is one minute and there is no seconds field.

When both the day of month and the day of week are restricted, the job runs when either one matches. crontab(5) says: if both fields are restricted (do not contain the star character), the command will be run when either field matches the current time. So 30 4 1,15 * 5 runs at 04:30 on the 1st, on the 15th and on every Friday, not only on a Friday that is the 1st or 15th. The test is made on the first character of the field, which is how cronie's source reads it: a field that starts with * counts as unrestricted even with a step, so 0 0 */2 * 1 means every second day of the month that is also a Monday, because then both must match. The tool describes both cases and explains which one applies.

Cron runs in the time zone of the machine, or the one set by CRON_TZ in cronie. The next run times are worked out in the zone you pick: each local clock time that matches the schedule is turned into a real moment with your browser's time zone data, so the offset from UTC and any daylight saving change are the zone's own. Clock changes need a rule, and cron programs differ. cronie's cron(8) says that local time changes of less than three hours are handled in a special way for jobs that run at a specific time: if the time was adjusted forward, the jobs that would have run in the skipped interval run immediately, and if it was adjusted backward, running the same job twice is avoided. Debian's cron(8) says the same and spells out which jobs are affected: those without a star in the minute or hour field. Jobs with a star there run by the new time, and cronie's source tests those same two fields. The crontab(5) page of cronie describes plain matching instead: a time that does not exist never matches, and a time that happens twice matches twice. The tool follows the cron(8) rule by default and can show plain matching, and it marks every run that a clock change affects. Other cron programs may differ, so check a run near a change on your own system.

Several other tools use the word cron for a different format. Quartz and Spring put a seconds field first, so they have six fields (Quartz allows a seventh, the year). Amazon EventBridge has six fields with no seconds and a year last. Quartz, Spring and EventBridge all use ? L W and # in the day fields, and EventBridge requires a question mark in one of the two day fields and counts the days of the week from 1. This tool does not read them: a six or seven field expression, or a field with ? L W or #, gets a message that says so rather than a wrong answer. If you paste a whole crontab line, the text after the fifth field is shown as the command and ignored. Names such as MON-FRI are accepted, as cronie allows, although Debian's crontab(5) says ranges or lists of names are not allowed, so use numbers if you are unsure.