CalConverters

Cron Expression Parser

Type a cron expression and see what it means in plain language, plus the next times it will run in the time zone you pick.

Files never leave your device

What this means

  • Every 15 minutes, from minute 0 to 59
  • From hour 9 to 17
  • Every day of the month
  • Every month
  • From Monday to Friday

Five fields, left to right

A cron expression is five space-separated fields — minute, hour, day-of-month, month, day-of-week — each naming which values of that unit make the schedule fire this tick. Take */15 9-17 * * MON-FRI: the minute field */15 expands to 0, 15, 30 and 45; the hour field 9-17 expands to every hour from 9 through 17; day-of-month and month are both left as *, matching everything; and MON-FRI narrows the day-of-week field to Monday through Friday. Put together, that's every 15 minutes, from 9am to 5pm, Monday to Friday — a typical business-hours job.

FieldPositionRange* means
Minute1st0–59every minute
Hour2nd0–23every hour
Day of month3rd1–31every day of the month
Month4th1–12 or JAN–DECevery month
Day of week5th0–7 (0 and 7 both mean Sunday) or SUN–SATevery day of the week

A step counts from where the range starts, not from zero

9-17/4 reads as "every 4th hour starting at 9, up to 17" — 9, 13, 17. A bare */4 is different: with no explicit start, it steps from the field's minimum, so */4 on the hour field is 0, 4, 8, 12, 16, 20. The two forms look similar but answer different questions — one steps through a slice of the field starting where you told it to, the other steps through the whole field from its own zero.

Tip: Reading an unfamiliar step expression, check what's on the left of the slash first: a bare * steps from the field's own zero, and a range steps from that range's own start. 9-17/4 and */4 on the same field land on entirely different hours.

The rule everyone gets backwards: day fields are OR'd, not AND'd

Cron ANDs every field against every other — except day-of-month and day-of-week: those two OR together whenever neither day field is *. 0 0 13 * FRI fires at midnight on the 13th of the month or on any Friday — not on a Friday that happens to be the 13th. Walk it forward from 1 January 2026: the schedule fires Friday 2 January, Friday 9 January, then the 13th itself (a Tuesday, matched purely on day-of-month), then Friday 16 January, and on. Only when one of the two fields is * does the rule collapse back to something that reads like AND: 0 0 * * FRI leaves day-of-month as *, so the OR has nothing on the other side, and the schedule is simply every Friday.

Time zone: what it changes, and the two days it complicates

A cron expression names a wall-clock time, not a fixed instant — 30 9 * * * means "9:30, in whichever zone you tell it," and picking a different zone changes which moment in UTC that resolves to while leaving the local reading untouched. Run that expression against 1 January 2026 in Asia/Ho_Chi_Minh and the first match lands at 02:30 UTC; run the identical expression in America/New_York and it lands at 14:30 UTC — twelve hours apart, both reading 09:30 on the wall clock they were asked about.

Two days a year make that resolution genuinely awkward, and only in a zone that observes DST. On 8 March 2026, clocks in America/New_York jump from 01:59 straight to 03:00, so 02:30 never happens that day — a daily job set for 30 2 * * * simply has no run on the 8th, then resumes on the 9th as normal. On 1 November 2026 the same zone falls back an hour, so 01:30 happens twice; a daily 30 1 * * * job still lists it once, resolved to the earlier of the two passes.

Tip: Pick the zone the job's schedule is actually meant to track — a server's own local time, or a user's. UTC never has a gap or a fold, but a schedule written in UTC drifts an hour off the intended local time for most of the year in any zone that observes DST.

Frequently asked questions

What do the five fields in a cron expression mean, in order?
Minute (0–59), hour (0–23), day-of-month (1–31), month (1–12 or JAN–DEC), and day-of-week (0–7, with both 0 and 7 meaning Sunday, or SUN–SAT), always in that order and always five fields. Take `*/15 9-17 * * MON-FRI`: the minute field expands to 0, 15, 30 and 45; the hour field expands to every hour from 9 through 17; day-of-month and month are left as `*`, matching everything; and day-of-week is narrowed to Monday through Friday. Put together, that's every quarter hour from 9am to 5pm, Monday to Friday.
Why does `0 0 13 * FRI` fire on the 13th or any Friday, not on Friday the 13th?
Cron ANDs every field against every other field, except day-of-month and day-of-week — those two are OR'd whenever neither day field is `*`. `0 0 13 * FRI` fires at midnight on the 13th of the month or on any Friday, whichever comes first; walking it forward from 1 January 2026 hits Friday the 2nd, Friday the 9th, then the 13th itself (a Tuesday, matched purely on day-of-month), then Friday the 16th. The rule only steps aside when one of the two fields is `*` — `0 0 * * FRI` leaves day-of-month as `*`, so there's nothing for the OR to combine with, and the schedule is simply every Friday.
Where does a step like `9-17/4` start counting from?
From the range's own start, not from the field's minimum. `9-17/4` is 9, 13, 17 — every fourth hour beginning at 9. A bare `*/4` is a different question: with no explicit start it steps from the field's own zero, so on the hour field that's 0, 4, 8, 12, 16, 20. The two forms can look almost identical and land on completely different hours.
Are day-of-week `0` and `7` the same thing?
Yes, both mean Sunday — it's a deliberate alias so a week can be written starting from either end. That's also why a range like `5-7` is legal and expands to Friday, Saturday and Sunday: it walks 5, 6, 7 and then folds the trailing 7 back down to 0, rather than rejecting the range for running past the field's usual 0–6 span.
What actually changes when I pick a different time zone?
The expression names a wall-clock time, not a fixed instant, so the zone changes which moment in UTC that wall-clock reading resolves to while the local time itself stays put. Point `30 9 * * *` at 1 January 2026 in Asia/Ho_Chi_Minh and the first match lands at 02:30 UTC; point the identical expression at America/New_York and it lands at 14:30 UTC — twelve hours apart, both reading 09:30 on the clock they were asked about.
What happens to a daily job scheduled for a time that doesn't exist, like 02:30 on the day clocks spring forward?
It's skipped, not shifted. On 8 March 2026, America/New_York's clocks jump from 01:59 straight to 03:00, so 02:30 never happens that day. A daily `30 2 * * *` job simply has no run on the 8th and resumes normally on the 9th — the tool shows the gap rather than guessing a nearby time to substitute.
Does a job fire twice on the day clocks fall back?
No — it's listed once. On 1 November 2026, America/New_York falls back an hour, so 01:30 happens twice that day. A daily `30 1 * * *` job still shows a single 1 November run, resolved to the earlier of the two passes, so a schedule preview never shows the same calendar day twice for what is meant to be one run a day.