Cron Expression Parser — Plain English & Next Run Times
Paste a crontab line, read what it means, and see exactly when it fires next — in your zone or UTC.
🔒 Runs in your browser — files never uploaded ⚡ No signup 💯 Free
Both day fields are restricted. Standard cron runs when either matches — day-of-month or weekday — not only when both do.
Upcoming runs
Field by field
Turn a five-field cron expression into a plain-English sentence and a list of the next run times. The schedule is computed for your local time zone or for UTC — the choice most servers actually run in — and every field is broken down so you can see the exact minutes, hours, days and months it expands to.
It also catches the classic mistakes: six fields (a Quartz/Spring expression with seconds), values out of range, a 31st in a month that has no 31st, and the two day fields being OR'd together when you meant AND.
How to use Cron Expression Parser
- Type or paste the expression —
*/15 9-17 * * 1-5, or a macro like@daily. - Read the sentence. If it doesn't say what you meant, the expression is wrong, not the tool.
- Check the next runs — switch to UTC if that's what your server uses. Most do.
- Use the field table to see exactly which values each field expands to.
The five fields
┌──────────── minute (0–59)
│ ┌────────── hour (0–23)
│ │ ┌──────── day of month (1–31)
│ │ │ ┌────── month (1–12 or JAN–DEC)
│ │ │ │ ┌──── day of week (0–7 or SUN–SAT; 0 and 7 are both Sunday)
* * * * *Each field takes a value, a range (1-5), a list (1,15), a step (*/10, 1-30/5) or * for "every". Names are accepted for months and weekdays and are case-insensitive.
The mistakes this parser is built around
- Day-of-month and day-of-week are OR'd.
0 0 1 * 1runs on the 1st of every month and on every Monday — not on Mondays that fall on the 1st. Standard cron has no way to express the AND; you do it in the script ([ $(date +\%d) -le 7 ] && …for "first Monday"). The parser flags this whenever both fields are restricted. - "Every N minutes" resets at the top of the hour.
*/7is minute 0, 7, 14 … 56, then 0 again — a four-minute gap. Only steps that divide 60 (or 24 for hours) are truly even; the run list shows the real spacing. - Six fields is not cron. Quartz, Spring and some cloud schedulers add a seconds field at the front (and
?,L,W,#). Paste one into a crontab and cron will reject it, or worse, misread it. - Impossible dates never run.
0 0 31 2 *is valid syntax that never fires;0 0 29 2 *fires once every four years. The next-runs list says so instead of showing an empty box.
Time zones — the silent killer
Cron runs in the system's zone, which on a server is almost always UTC. "0 9 * * 1-5" is 09:00 UTC — 10:00 in London in winter, 11:00 in summer, 05:00 in New York. Preview in UTC here, and remember that a local-time crontab shifts by an hour at every DST change: a 02:30 job may run twice, or not at all, on those two nights a year. If the exact local hour matters, run the job in UTC and convert in the script.
Shortcuts
@hourly, @daily (or @midnight), @weekly, @monthly and @yearly (or @annually) expand to the obvious expressions and are shown here as such. @reboot runs once at startup and has no schedule to display.
Frequently asked questions
What does */5 mean, and is it really every 5 minutes?
*/5 in the minute field means minutes 0, 5, 10 … 55 — every five minutes, evenly, because 5 divides 60. */7 is not every seven minutes: it runs at 0, 7 … 56 and then resets to 0, leaving a four-minute gap each hour. The next-runs list makes the real spacing visible.
How do I run something on the first Monday of the month?
You can't in standard cron — the day fields are OR'd, so 0 9 1-7 * 1 runs on days 1–7 and on every Monday. Schedule 0 9 * * 1 and test the date in the command: [ "$(date +\%d)" -le 07 ] && /path/to/job. (The % must be escaped in crontab.)
Why does my six-field expression fail?
The leading field is seconds, which Quartz, Spring and some cloud schedulers support but classic cron does not. Drop it for a crontab. Likewise ?, L, W and # are Quartz-only.
Which time zone does cron use?
The system's — on servers, almost always UTC. Preview in UTC here and convert in your head, or set CRON_TZ=Europe/London at the top of the crontab on systems that support it. Note that local-time schedules shift at DST changes; jobs at 02:30 can run twice or not at all on those nights.
Is 0 or 7 Sunday?
Both, in every modern cron. SUN also works. Ranges like 5-7 (Friday to Sunday) are fine; the parser maps 7 to 0 internally.