A cron expression is a compact way to write a schedule: */5 * * * * means "every 5 minutes" and 0 9 * * 1-5 means "at 9:00 on weekdays". It is used by Linux crontab, CI systems, container schedulers and many job libraries, and it is easy to get subtly wrong. This tool reads the expression the same way a scheduler does, says what it means in your language, breaks it down field by field and lists the next 10 times it will run in the time zone you choose. The expression never leaves your browser.
The five fields
Fields are separated by spaces, in this order. Put a sixth field in front and it becomes the seconds, as in Spring and Quartz.
| Field | Allowed values | Names |
|---|
| minute | 0 to 59 | |
|---|
| hour | 0 to 23 | |
|---|
| day of month | 1 to 31 | |
|---|
| month | 1 to 12 | JAN to DEC |
|---|
| day of week | 0 to 7, where 0 and 7 are both Sunday | SUN to SAT |
|---|
Each field accepts * for every value, a number, a list such as 1,15, a range such as 9-17, and a step: */15 means every 15th value, 10-30/5 means every 5th value from 10 to 30 and 5/20 means every 20th value starting at 5. Names can be used in lists and ranges in any case, for example MON-FRI. The shortcuts @hourly, @daily, @midnight, @weekly, @monthly and @yearly are understood too.
Day of month and day of week
When both the day-of-month and the day-of-week fields are restricted, classic cron runs the job when either one matches, not both. So 0 0 13 * 5 does not mean "Friday the 13th": it means "every 13th, and every Friday". In October 2026 it fires on the 2nd, 9th, 13th, 16th, 23rd and 30th. If one of the two fields starts with *, only the other one counts, and for "Friday the 13th" you need to check the date inside the job. This tool follows that rule and shows a note when it applies.
Time zones and daylight saving
A cron expression has no time zone of its own: the scheduler uses the zone of the machine or the setting of the service. Pick the zone yours uses, and the run times above are computed in it. Clock changes need a decision, and this tool makes it explicit. When the clocks jump forward, the skipped hour does not exist, so a job set for 02:30 is skipped that day (in New York on 8 March 2026 the clock went from 01:59 to 03:00). When the clocks go back, a time such as 01:30 happens twice, and the job runs once, at the first 01:30 (1 November 2026). Real schedulers differ in these edge cases, so keep important jobs away from the hour of the change, or run them in UTC.
What is not supported
The special characters ?, L, W and # (last day, nearest weekday, the n-th weekday) and a trailing year field belong to Quartz and Spring schedulers, not to classic cron. This tool says so instead of guessing; rewrite the expression with plain fields, or check the documentation of the scheduler you use. The shortcut @reboot has no schedule to explain.
Common mistakes
- Reading the fields in the wrong order, for example writing the hour first.
- Using
*/n with an n that does not divide the range evenly. - Forgetting that day-of-week 0 and 7 are both Sunday, and that a leading seconds field shifts every other field by one.
- Assuming the schedule runs in your local time when the server uses UTC.
To check what a schedule produces in a log, the regex tester helps with the line patterns, and the diff checker compares two versions of a crontab.
