Paste a 5-field cron expression. Get the plain-English meaning and the next 10 fire times, shown in whichever timezone matters for you.
At 9:00 on Monday, Tuesday, Wednesday, Thursday, Friday.
Presets
Next 10 fire times (UTC)
1Fri Apr 24, 2026 · 09:00UTC
2Mon Apr 27, 2026 · 09:00UTC
3Tue Apr 28, 2026 · 09:00UTC
4Wed Apr 29, 2026 · 09:00UTC
5Thu Apr 30, 2026 · 09:00UTC
6Fri May 1, 2026 · 09:00UTC
7Mon May 4, 2026 · 09:00UTC
8Tue May 5, 2026 · 09:00UTC
9Wed May 6, 2026 · 09:00UTC
10Thu May 7, 2026 · 09:00UTC
Questions
FAQ
Which cron syntax does this support?
Standard 5-field POSIX cron: minute, hour, day-of-month, month, day-of-week. Each field accepts the usual operators — comma lists, hyphen ranges, asterisk wildcards, and slash steps (e.g. */5 or 0-30/10). It does not yet support extended Quartz syntax (seconds field, year field, L/W/# operators).
Why are day-of-month and day-of-week treated specially?
Standard cron has a quirk: when both day-of-month and day-of-week are restricted, the schedule fires on either match, not both. So "0 0 1 * 1" fires on the 1st of every month AND on every Monday — not just Mondays that fall on the 1st. We follow this convention because virtually every cron implementation does.
Does the next-fire-time preview honour DST?
Yes. We resolve each candidate moment in the timezone you select using the IANA rules, so a job scheduled for 02:30 daily in a DST zone will skip the day the clock springs forward (because 02:30 doesn't exist that day) and double-fire the day it falls back, just like real cron daemons that respect TZ.
Why doesn't the description match what I expected?
Plain-English description of cron is a translation, and translations have edge cases. If you see "every minute of every hour" instead of "every minute," it's because both fields use the wildcard. The description is best-effort — the next-fire-times list is the authoritative source of truth for what your job will actually do.