Cron Schedule Simulator

What this simulates

The expression uses the classic five fields — minute, hour, day of month, month, day of week — with lists (1,15), ranges (8-11), steps (*/15, 0-23/2), month and day names (jan, mon-fri) and 0 or 7 for Sunday, as described in the cronie crontab(5) manual. Steps are counted inside the field, so */23 in the hour field means hours 0 and 23. If both day of month and day of week are restricted (neither contains *), a run happens when either matches, so 30 4 1,15 * 5 runs on the 1st, the 15th and every Friday.

Clock changes: skipped and repeated times

When the clocks go forward, some local times never exist (in the UK 01:30 on the last Sunday in March); when they go back, some occur twice. Implementations differ, which is why this tool offers three behaviours:

• cron (cronie) — from the cron(8) manual: for time changes of less than three hours, jobs that run at a specific time or less often than hourly are run immediately when the clock jumps forward past their time, and are not run a second time when the clock goes back. Jobs that run more often (a * in the minute or hour field) are scheduled normally: nothing is caught up, and repeated times run twice. Changes of three hours or more are treated as corrections and the new time is used at once.
• Literal local time — what the crontab(5) manual says the field matching means: a time that does not exist never matches, so the run is skipped; a time that occurs twice matches twice, so it runs twice.
• Run in UTC — the schedule is read as UTC, so nothing is skipped or repeated. This is the safest choice for jobs that must run exactly once a day.

Not every scheduler behaves like cronie. Other cron versions, systemd timers, Kubernetes CronJobs, cloud schedulers and libraries each have their own rules, and the same expression can run zero, one or two times on a clock-change night. Check the documentation of the scheduler you actually use, and avoid times between 01:00 and 03:00 for jobs that must not be skipped or doubled. Some cron versions let you set the time zone of a crontab with the CRON_TZ variable. Time-zone rules come from your browser's IANA database, so future dates follow the rules known today and could change if governments change the rules.

Source / Last verified (26 September 2026): cronie manual pages — cron(8), "Daylight Saving Time and other time changes" and crontab(5) (field syntax, steps, names, the day-of-month/day-of-week rule, @-shortcuts and the note on non-existent and repeated times). The simulation of the cronie behaviour follows these manuals; the detail of which jobs count as "frequent" is modelled as a * in the minute or hour field and other implementations may differ.