Cron Syntax Explained: A Complete Guide to Cron Expressions

A cron expression is a short line of text that tells a scheduler when to run a job. It looks cryptic because it packs a whole calendar rule into a few tokens, but the grammar is small. Once you know what each field means and how ranges and steps are matched, you can read almost any expression.

The five fields

Standard Unix cron uses five fields separated by spaces. The scheduler runs the job whenever the current time matches the fields.

30 14 * * *      # 14:30 every day
0 9 * * MON-FRI  # 09:00 Monday to Friday
0 0 1 * *        # midnight on the 1st of each month

Wildcards, lists, ranges and steps

• * matches every value of the field.
• 1,15 is a list: the values 1 and 15.
• 9-17 is a range, inclusive of both ends.
• */20 is a step over the whole field. In the minute field it matches 0, 20 and 40.
• 1-30/5 is a step inside a range: 1, 6, 11, 16, 21 and 26.
• 1,5,10-20/2 combines a list, a single value and a stepped range.

Steps are tied to calendar values. */20 does not mean twenty minutes after the last run; it means the minutes that are multiples of 20. A step that does not divide the field evenly shows the effect clearly: */7 in the minute field matches 0, 7, 14 and so on to 56, and then restarts at 0 in the next hour, so the last gap is only four minutes.

Month and weekday names

Names such as JAN, FEB, MON and TUE are usually accepted in the month and weekday fields, and make a schedule easier to read. They also avoid a common source of bugs: weekday numbers are not the same everywhere. A schedule written as MON-FRI means the same thing in every dialect that accepts names, while 1-5 means Monday to Friday in Unix cron but Sunday to Thursday in Quartz.

Macros

Many cron implementations accept shortcuts: @hourly, @daily (or @midnight), @weekly, @monthly and @yearly (or @annually). @reboot is different. It runs a job when the cron daemon starts, so it is an event, not a time, and there is no next run time to calculate. Macros are not part of every scheduler, so check yours before relying on them.

Common mistakes

• Using six fields in a five-field scheduler. A leading seconds field shifts every other field by one place.
• Expecting */5 in the hour field to mean every five hours counted from now. It matches 0, 5, 10, 15 and 20 o'clock and then restarts.
• Assuming a 17:00 end in 9-17 means the last run is at 17:00. With */15 the last run is 17:45, because the whole of hour 17 matches.
• Restricting both day-of-month and day-of-week and expecting both to apply. In Unix cron a day matches if either does.
• Forgetting the timezone. The expression has none; the scheduler supplies it.

Check an expression before you deploy it

Reading an expression is easier when you can see what it actually does. The Cron Builder on DevCraftKit parses an expression in your browser for the dialect you choose, explains each field, lists the next run times in the timezone you select, and reports errors field by field. Nothing is uploaded or scheduled; it only analyzes the text.

Conclusion

Five fields, a handful of operators and a few names cover most schedules. The real traps are the differences between dialects, the way day fields combine, and timezones, which are the subject of the related articles on five-field and six-field cron, day-of-month versus day-of-week, and daylight-saving time.