Cron Expression Parser
Type a cron expression or pick a preset. The parser explains it in plain English, breaks down each field, and shows the next 5 times it would fire — in your local timezone, updated live. No upload.
Next 5 fire times
The 5-field format
┌──────────── minute (0–59)
│ ┌────────── hour (0–23)
│ │ ┌──────── day of month (1–31)
│ │ │ ┌────── month (1–12 or JAN–DEC)
│ │ │ │ ┌──── day of week (0–6 or SUN–SAT, both 0 and 7 = Sun)
│ │ │ │ │
* * * * * command-to-runEach field accepts:
*— any value1,3,5— list1-5— range*/15— every Nth value1-30/2— range with stepJAN-DEC,SUN-SAT— case-insensitive names (months and days only)
Common expressions
| Expression | Means |
|---|---|
* * * * * | Every minute |
*/5 * * * * | Every 5 minutes |
0 * * * * | Every hour, on the hour |
0 9 * * * | Every day at 9:00 |
0 9 * * 1-5 | Weekdays at 9:00 |
0 0 1 * * | First of every month at midnight |
0 0 * * 0 | Sundays at midnight |
0 0 1 1 * | New Year's at midnight (= @yearly) |
30 14 * * 1,3,5 | Mon/Wed/Fri at 14:30 |
The big gotcha — day-of-month vs day-of-week
If you set both the day-of-month and day-of-week fields,
Vixie cron fires when either matches — not both.
So 0 0 15 * 1 fires on the 15th of every month
or on any Monday. Almost nobody expects this.
The fix: leave one of the two as *. If you really want
the intersection (e.g., "the 15th, but only if it's a Monday"), you
need a different scheduler or a runtime check inside your job.
Why client-side
Cron expressions are a great example of "easy to get wrong, no reason to upload." Past your input through a server-side parser leaks your scheduling intent. The math is small enough to run in your browser — this tool ships about 5 KB of JS for the full parser + describer + next-fire iterator.
Limitations
- 5 fields only — not 6-field Quartz with seconds.
- No DST handling — fire times use your local browser timezone but don't model DST transitions exactly. Most cron implementations don't either; jobs at 02:30 simply don't run on spring-forward day in DST-affected zones.
- No leap-second handling — same as above; almost no cron implementation does this.
- No
L,W, or#Quartz extensions — last-day-of-month, weekday-nearest, nth-weekday-of-month. These are Quartz-specific.
Related tools
- epoch.tooljo.com — convert cron-fired Unix timestamps back to readable dates.
- date.tooljo.com — for the date math when you're computing intervals between fires.
- DST and date math — why your cron job might run twice (or zero times) on DST transition days.
FAQ
Is anything I enter sent to a server?
No. Parsing and next-fire calculation run in your browser. Open DevTools → Network and confirm — zero requests when you type.
Which cron dialect does this support?
Standard Vixie/POSIX cron — 5 fields plus the special strings (@hourly, @daily, @weekly, @monthly, @yearly, @midnight, @annually). Named months (JAN-DEC) and days (SUN-SAT) are supported. Step values (*/5), ranges (1-10), lists (1,5,15), and range-with-step (0-30/5) all parse correctly.
What about Quartz / 6-field cron?
Not yet. Quartz adds a seconds field at the start (and an optional year at the end), used by Spring's @Scheduled and Quartz Scheduler. Most server crons (cron.d, systemd timers, Kubernetes CronJob, GitHub Actions) use the standard 5-field syntax this tool supports.
Why does '0 0 * * 0' equal 'Sundays at midnight' but '0 0 * * 7' also works?
Cron is forgiving here: in the day-of-week field, both 0 and 7 mean Sunday. Some implementations accept only one or the other; we accept both for compatibility. If you're writing for a specific cron implementation, check its docs.
What's the deal with day-of-month + day-of-week?
If you specify both day-of-month (e.g., 15) AND day-of-week (e.g., 1 for Monday), the job fires when either matches — i.e., on the 15th of any month OR on any Monday, not their intersection. This is the original Vixie cron behaviour and trips up almost everyone. The parser displays the consequence in the next-fire times so you can verify.
What's the smallest interval cron supports?
1 minute. Sub-minute scheduling needs a different scheduler (systemd timers can do seconds; Kubernetes CronJob is limited to minute granularity).