This cron expression builder and explainer translates a 5-field cron
expression into plain English and previews its next 10 run times in the timezone you
choose — including correct daylight saving time handling. Everything runs in your browser.
How to use it
Type a cron expression, pick the timezone it should be evaluated in, and click "Explain &
preview". You'll get a plain-English description and a list of the next 10 times it would
fire.
Reading the 5 fields
In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12 or JAN–DEC), and day
of week (0–6 or SUN–SAT). Each field accepts a single value, a comma-separated list, a
range (1-5), a step (*/15), or an asterisk for "every value."
Why timezone-aware matters
A bare cron expression has no timezone of its own — it's evaluated in whatever timezone the
scheduler running it is configured for. That's a common source of scheduling bugs when a
team is distributed across timezones, or when a server's timezone doesn't match what the
person who wrote the schedule assumed. Picking the timezone explicitly here removes that
ambiguity before you ship the schedule.
Frequently asked questions
What format does this tool expect?
Standard 5-field cron: minute, hour, day-of-month, month, day-of-week (e.g. "0 9 * * MON-FRI"). Ranges, steps, lists, and named months/weekdays are all supported.
Why does the timezone matter for a cron expression?
A cron expression like "0 9 * * *" means "9am" — but 9am in which timezone? Most schedulers (including cron itself) evaluate the expression in a specific timezone, usually the server's. This tool lets you pick the timezone explicitly so "9am" means what you actually intend, including correct handling of daylight saving time transitions.
Does it handle daylight saving time correctly?
Yes — the underlying date math is timezone-aware, so a schedule like "0 9 * * *" in America/New_York correctly stays at 9am local time across the spring-forward and fall-back transitions, rather than drifting by an hour.
Why does this tool use a library instead of writing its own cron parser?
Cron scheduling combined with timezone and DST math is a well-known source of subtle bugs — leap years, month-end edge cases, ambiguous DST-transition hours. This tool uses cron-parser and cronstrue, two widely used, independently tested libraries, rather than risk a hand-rolled implementation getting an edge case quietly wrong.
Is my cron expression sent anywhere?
No. Everything — parsing, the plain-English explanation, and the next-10-runs calculation — happens entirely in your browser via JavaScript bundled into the page.