Cron expression explainer
Paste a schedule such as 30 9 * * 1-5 and see what it means, whether it is valid, and when it will run next in your time zone. It explains the rules that catch people out, like the day-of-month and day-of-week either/or rule and daylight saving. Nothing is uploaded; it all runs in your browser.
Five fields: minute, hour, day of month, month, day of week. A whole crontab line works too; the command after the schedule is ignored.
Try an example
What it means
At 09:30 on Monday to Friday
Next run times
Leave empty to start from now. Pick a date to see what happens around a clock change.
Working out the current time…
Field by field
| Field | Written | Means | Allowed |
|---|---|---|---|
| Minute | 30 | 30 | 0-59 |
| Hour | 9 | 9 | 0-23 |
| Day of month | * | every day of the month | 1-31 |
| Month | * | every month | 1-12 or JAN-DEC |
| Day of week | 1-5 | Monday to Friday | 0-7 or SUN-SAT (0 and 7 are Sunday) |
Rules worth knowing
- •Day of month and day of week: if both are restricted, the job runs when either one matches. 0 0 13 * 5 runs on every 13th and on every Friday, not only on Friday the 13th. If either field starts with *, both must match.
- •Clock changes (Vixie cron and cronie): when clocks jump forward, a job with a fixed minute and hour that falls in the skipped time runs once right after the jump, while a job whose minute or hour starts with * skips those minutes. When clocks go back, fixed-time jobs run once and * jobs run in both copies of the repeated hour.
- •Other schedulers (systemd timers, Kubernetes CronJob, cloud schedulers, Quartz) can treat clock changes and the day fields differently. Check your scheduler's documentation for the edge cases.
How it works
- •The expression is read the way classic cron reads it (Vixie cron and cronie, used on most Linux systems and macOS): five fields, names such as JAN and MON, ranges, lists and steps, with 0 and 7 both meaning Sunday. The @daily-style shortcuts are expanded.
- •The description is built from the parsed fields, not guessed from the text, so 0,15,30,45 and */15 both read as every 15 minutes.
- •Run times are found by walking the calendar in the time zone you pick. Zone rules come from your browser's built-in time zone data, and clock changes follow cron's own rules: skipped times run once after the jump for fixed-time jobs, and repeated times run once or twice depending on whether the minute or hour field starts with *.
- •We checked the run times against a separate reference written in Python that simulates the cron daemon minute by minute through daylight saving changes in New York, London, Lord Howe Island, Kolkata and UTC.
Questions
- Why does my job run on days I did not expect?
- If you restrict both day of month and day of week, cron runs when either one matches. 0 0 1 * 1 runs on the 1st of every month and on every Monday. If you want the 1st only when it is a Monday, cron alone cannot express that; a common workaround is a date test inside the command.
- What happens to a job at 02:30 when the clocks change?
- In Vixie cron and cronie, if 02:30 is skipped because clocks jump forward, a job with a fixed minute and hour runs once right after the jump. If 01:30 happens twice because clocks go back, a fixed-time job runs only the first time, while a job whose minute or hour field starts with * runs both times. Other schedulers may differ, so the tool marks those runs.
- Does it support Quartz or AWS cron with ? L W and #?
- No. Those dialects have different rules for the day fields, a seconds field and an optional year. The tool recognises their syntax and tells you, instead of guessing. It does support an optional seconds field in front of the usual five, as used by Spring and node-cron.
- Is my crontab sent anywhere?
- No. Parsing and the run-time calculation happen on this page in your browser. If you paste a whole crontab line, the command after the schedule is ignored and never leaves the page.