About the Cron Expression Parser
This cron expression parser reads a standard five-field crontab schedule — minute, hour, day of month, month and day of week — and explains it in plain English, then lists exactly when it will run next. It understands lists (1,15), ranges (9-17), steps (*/15, 0-30/10), month and weekday names (JAN, MON-FRI), Sunday as 0 or 7, and the @hourly, @daily, @weekly, @monthly and @yearly shortcuts.
Use it to double-check a schedule before adding it to crontab, a Kubernetes CronJob, GitHub Actions, a CI pipeline or a cloud scheduler, or to decode an entry you found on a server. The field table shows how each part was interpreted, which makes mistakes like swapping the day and month fields obvious.
Run times are listed in the schedule’s own time zone as wall-clock times, starting just after the date and time you choose; daylight-saving shifts are not applied, so around a clock change a real local-time cron may skip or repeat a run that this list shows once. Like Vixie cron, when both day of month and day of week are restricted the job runs when either one matches.
How to use the cron expression parser
- 1Paste a cron expression such as 0 9 * * 1-5 or @daily.
- 2Read the plain-English description to confirm it does what you intend.
- 3Choose a start date and time to preview the next run times.
- 4Check the field table if the schedule looks wrong.
- 5Copy the expression into crontab -e, your CronJob or CI config.
Formula and method
Each of the five fields is expanded into the set of values it allows: * means every value, a-b is a range, a,b,c is a list and /n keeps every nth value of the range (so */15 in the minute field means 0, 15, 30 and 45). Month and weekday names are accepted, and weekday 7 is treated as Sunday like 0.
A time matches when the minute, hour and month are all in their sets and the day rule passes. If either day field is *, the other must match; if both are restricted, a day matches when either the day of month or the day of week matches (Vixie cron behaviour). Next runs are found by scanning forward day by day from the start time.
- minute
- 0–59
- hour
- 0–23 (24-hour clock)
- day of month
- 1–31
- month
- 1–12 or JAN–DEC
- day of week
- 0–7 or SUN–SAT (0 and 7 are Sunday)
Worked examples
Every 15 minutes during business hours
*/15 gives minutes 0, 15, 30, 45 and 9-17 gives nine hours, so the job runs 4 × 9 = 36 times on each weekday. 1 January 2026 is a Thursday, so the first run after midnight is 09:00 that morning.
Monthly report at midnight
The job runs at 00:00 on the 1st of every month. Runs are listed strictly after the start moment (1 January 00:00), so the next one is 1 February 2026, a Sunday.
Weekly backup on Sunday night
SUN is day 0. The first Sunday after Tuesday 10 March 2026 is 15 March, so the backup next runs at 02:30 that morning.
Day-of-month OR weekday
Because both day fields are restricted, cron runs at noon on every 13th AND every Friday — not only on Friday the 13th. The first match after 1 February 2026 is Friday 6 February.
Weekend-and-Friday job with Sunday written as 7
Day-of-week 7 is another way to write Sunday, so 5-7 means Friday, Saturday and Sunday. The start moment is Thursday 1 January 2026 at 00:00, so the first run is midnight on Friday 2 January.
Frequently asked questions
What do the five fields in a cron expression mean?+
In order: minute (0–59), hour (0–23), day of month (1–31), month (1–12) and day of week (0–7, where 0 and 7 are Sunday). An asterisk means “every” value of that field.
How do I run a cron job every 5 minutes?+
Use */5 * * * *. The */5 step in the minute field matches minutes 0, 5, 10 … 55 of every hour, every day.
What does 0 0 * * * mean?+
It runs once a day at midnight (00:00). It is the same as the @daily or @midnight shortcut. Use 0 9 * * * for 9 AM every day.
Why did my job run on the wrong day?+
If you set both day of month and day of week (e.g. 0 0 1 * MON), standard cron runs when either matches — the 1st and every Monday. Use one of the two fields and leave the other as *.
Which time zone does cron use?+
Classic cron uses the server’s local time zone, while GitHub Actions and many cloud schedulers use UTC. Around daylight-saving changes a local-time job can be skipped or run twice.