Cron expression generator

How to read a cron expression

A cron expression is five fields separated by spaces. The job runs at every minute where all five match (with one exception for the two day fields, below):

• * means every value. , separates a list. - is a range, and ranges cannot wrap around (write 5-6,0 rather than 5-0).
• /n is a step: */15 in the minute field is 0, 15, 30 and 45; 9-17/2 in the hour field is 9, 11, 13, 15 and 17. Steps count from the start of the range and restart each hour, day or month, so */7 minutes runs at :56 and then :00, only 4 minutes later.
• Shortcuts: @hourly, @daily (also @midnight), @weekly (Sunday 00:00), @monthly and @yearly (also @annually). @reboot runs at start-up and has no schedule.
• Six or seven fields, ?, L, W and # belong to Quartz, Spring or AWS EventBridge, not standard cron. The checker tells you which field to remove.

Worked example

*/15 9-17 * * 1-5 reads "every 15 minutes, between 09:00 and 17:59, Monday to Friday". Minute */15 gives 0, 15, 30, 45; hour 9-17 includes the whole 17:00 hour, so the last run of the day is 17:45, not 17:00. That is 4 runs an hour for 9 hours, 36 runs a day. Checked at 17:50 on Friday 23 October 2026, the next runs are Monday 26 October at 09:00, 09:15 and 09:30. To stop at 17:00 exactly, use two lines: */15 9-16 * * 1-5 and 0 17 * * 1-5.

The day-of-month and day-of-week trap

When both day fields are restricted, cron runs when either matches. 0 0 13 * 5 does not mean "Friday the 13th": it runs on the 13th of every month and on every Friday. If either field starts with *, both must match, which is why 0 0 */2 * 5 runs only on odd-numbered days that are Fridays. The explainer points this out whenever it applies. To run on the first Monday of the month, use 0 9 1-7 * * and check the weekday inside the command, for example [ "$(date +\%u)" = 1 ] && ./report.sh (in a crontab, % must be written as \%).

Time zones and daylight saving

Cron uses the clock of the machine or service that runs it. A server's crontab follows the server's time zone (often UTC on cloud servers). GitHub Actions schedules are always in UTC. Kubernetes CronJobs use the controller's time zone, usually UTC, unless you set spec.timeZone. Pick the zone above to see the runs as that machine will.

On the night the clocks change, some times do not exist and others happen twice. The run list follows cronie and Vixie cron, the cron on most Linux systems: a fixed-time job whose time is skipped runs right after the clocks jump forward, and one whose time repeats runs only once. Jobs with * in the minute or hour field just follow the clock. For example, 30 1 * * * in Europe/London runs at 02:00 BST on 29 March 2026, because 01:30 does not exist that night, and once at the first 01:30 on 25 October 2026. Other schedulers (systemd timers, cloud schedulers) can handle these nights differently, so avoid 01:00-03:00 for jobs that must run exactly once. To compare clock times between zones, use the time zone converter.