Cron Explainer
Turn a 5-field cron expression into plain English and the next run times.
Runs entirely in your browser — nothing you paste is uploaded.
About Cron Explainer
Five fields — minute, hour, day-of-month, month, day-of-week — and almost nobody reads them correctly at a glance. This turns an expression into a sentence and then shows the next five times it will actually fire in your timezone, which is the check that catches the mistakes a description alone won't.
All the standard syntax is supported: `*` for every value, `*/n` for steps, `a-b` for ranges, `a-b/n` for stepped ranges, comma-separated lists, and three-letter names for months and weekdays. Sunday can be written as `0` or `7` — both are valid POSIX and both resolve to the same day here, which is a case a surprising number of parsers reject.
The rule that catches everyone is the day-of-month and day-of-week interaction. When both are restricted, cron ORs them rather than ANDing: `0 0 13 * 5` fires on the 13th of every month *and* on every Friday, not only on Friday the 13th. When only one is restricted, it behaves as you'd expect. This is genuinely how the POSIX spec defines it, and it's a bug source in scheduling code that nobody notices until a job runs four times as often as intended.
Two more traps worth naming. `*/7` on minutes does not mean 'every 7 minutes' — it means minutes 0, 7, 14, 21, 28, 35, 42, 49, 56, and then a 4-minute gap at the top of the hour, because the step restarts. And a job scheduled at 02:30 either fires twice or not at all on daylight-saving transitions, unless your cron runs in UTC — which is the argument for running it in UTC.
Frequently asked
›Is `0 0 * * 7` valid for Sunday?
Yes. POSIX cron accepts both 0 and 7 for Sunday, and this parser resolves them to the same day — `0 0 * * 0`, `0 0 * * 7` and `0 0 * * sun` all produce the same schedule.
›Why does my job with both a day-of-month and a day-of-week run too often?
Because cron ORs those two fields when both are restricted. `0 0 13 * 5` means 'the 13th, or any Friday', not 'Friday the 13th'. To get an AND you need a day-of-week-only schedule plus a date check inside the job.
›Does `*/5` really mean every 5 minutes?
In the minute field, yes — 60 divides evenly by 5. But `*/7` gives 0, 7, 14 … 56 and then jumps 4 minutes at the hour boundary, because the step sequence restarts each hour. Steps only behave intuitively when they divide the field's range.
›What timezone does cron use?
The system's local timezone, unless the daemon or the platform says otherwise. That means daylight-saving transitions can skip or repeat a job. Run scheduled jobs in UTC wherever you can — the next-run times shown here are in your browser's local timezone for readability.
›What about 6-field expressions with seconds?
Not supported — those are a Quartz and Spring extension, not standard cron, and the leading field is seconds rather than minutes. Pasting one produces a field-count error rather than a silently wrong schedule.