Translate any 5-field cron expression into plain words, see its next five run times in your time zone, and get errors that name the field at fault. Free, no sign-up — runs locally in your browser.
Five fields, read left to right
A cron expression is a schedule written as five space-separated
fields — minute, hour, day of month, month, day of
week — and it fires whenever the current time matches all
of them (with one famous exception, covered below). Every field
accepts the same grammar: * for every value, a single
number, an inclusive range like 9-17, a step like
*/15, and comma-separated lists mixing all of those.
Months and weekdays also accept their three-letter English names,
so 0 9 * JAN MON is 09:00 on Mondays in January. The
parser above explains any expression in plain words and lists its
next five run times, and when an expression is wrong it says which
field is wrong and why — a job that silently never runs is the
worst outcome cron offers, and it usually starts with a typo
nobody could see.
The rule that catches everyone
Day of month and day of week do not combine the way intuition
says. If only one of them is restricted, it alone decides. If
both are restricted, the job runs when either
matches — 0 9 13 * 5 fires on the 13th of every month
and on every Friday. This is not a bug in any particular cron; it
is the documented behaviour of the original Vixie cron, preserved
by every compatible scheduler since. The practical advice: leave
one of the two fields as * unless the "or" behaviour
is genuinely what you want, and let the description above confirm
your intent — it calls the rule out whenever both fields are set.
Time zones and the clock you cannot see
Cron expressions carry no time zone: the same five fields mean
different wall-clock times on different machines. The next runs
listed here are computed in your browser's time
zone, named under the list, because that is the clock you
are planning against. Before trusting a schedule in production,
check the target machine's zone — servers default to UTC far more
often than laptops do — and remember daylight saving: on systems
that follow local time, a job in the spring-forward gap may be
skipped and a job in the fall-back overlap may run twice.
Schedules around 02:00–03:00 local deserve a second thought twice
a year. For a deeper tour of how Unix time itself works, the
guide on Unix timestamps explained
pairs well with this tool.
Frequently asked questions
What are the five fields, in order?
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, where both 0 and 7 mean Sunday). So "30 4 * * 1-5" reads: minute 30, hour 4, any day of the month, any month, Monday to Friday — 04:30 on weekdays. The order is the single most common source of cron confusion: new users routinely read the first field as hours, which is how a job meant for 4 a.m. ends up running every hour at minute 4.
What do *, / and - mean in a field?
"*" means every value in the field's range. "*/15" in the minute field means every 15th value — 0, 15, 30, 45. "9-17" is an inclusive range, "1,15" a list, and they combine: "0,30 9-17 * * *" runs on the hour and half hour through the working day. A step after a range ("9-17/2") takes every second value inside that range. This parser accepts all of these, plus month and weekday names, and rejects anything else with an error that names the field at fault.
Why did my job run on a Friday AND on the 13th?
Because of cron's oldest rule. When both the day-of-month and day-of-week fields are restricted (neither is *), the job runs when EITHER matches — not when both do. "0 9 13 * 5" means 09:00 on every 13th and on every Friday, so Friday the 13th is not special; it just matches twice over. When one field is *, the other alone decides. The description on this page says so explicitly whenever both are restricted, because this rule surprises everyone exactly once.
What time zone are the next runs shown in?
Yours — the time zone of the device you are reading this on, named on the page next to the times. Cron itself has no time zone concept: a crontab means whatever the local clock on the server says, which is why a job tuned to "9 a.m." in one country fires at midnight after the server is migrated elsewhere, and why comparing this page's preview against a server in another zone needs the server's zone, not yours. Daylight-saving transitions can also shift or skip a run on systems that follow local time.
Does this cover Quartz, @daily and seconds?
No — this is the standard 5-field Unix format used by crontab, systemd timers' cousins and most CI schedules. It does not support a seconds field, Quartz's 6–7 field expressions with L, W and #, or the @daily / @every shortcuts some systems layer on top. If your expression has six fields, it is probably Quartz or a seconds-extended dialect, and translating it means dropping or folding the extra field — reading it as standard cron would silently shift every field's meaning.
Dev