Cron explainer
Paste a cron expression to read it in plain English and see when it runs next, in any time zone.
Schedule
Example: paste your own cron expression above.
Fields
| Field | Written | Matches |
|---|---|---|
| Minute | 30 | 30 |
| Hour | 9 | 9 |
| Day of month | * | every value |
| Month | * | every value |
| Day of week | 1-5 | Mon–Fri |
- Field
- Minute
- Written
- 30
- Matches
- 30
- Field
- Hour
- Written
- 9
- Matches
- 9
- Field
- Day of month
- Written
- *
- Matches
- every value
- Field
- Month
- Written
- *
- Matches
- every value
- Field
- Day of week
- Written
- 1-5
- Matches
- Mon–Fri
Next runs
in UTCThe next run times appear here once the page has loaded.
How it works
Cron is the Unix scheduler. Each line of a crontab has five time fields and a command: 30 9 * * 1-5 backup.sh runs the backup at 09:30 on weekdays. A * means every value, 1-5 a range, 1,15 a list and */15 every 15th value. Months and weekdays take names like JAN and MON; Sunday is 0 or 7.
When both day fields are set, cron runs on days that match either one. 0 0 1 * MON runs on the 1st and on every Monday, not only on Mondays that are the 1st. If one of them starts with * (like */2), both have to match. This page follows Vixie cron and cronie, the cron on most Linux systems.
Cron uses the server's own time zone, which is often UTC on cloud machines, not yours. Set the zone above to the server's. cronie can be told another zone with a CRON_TZ= line, and Kubernetes CronJobs have a timeZone field. GitHub Actions schedules always run in UTC.
When clocks change for daylight saving time, a job at a fixed time inside the skipped hour runs right after the jump, and one inside a repeated hour runs once. Jobs with * in the minute or hour follow the clock, so they miss the skipped hour and run twice in the repeated one. Quartz extras (L, W, #, ?) aren't read here. To check what a date is in other zones, use the time zone converter; for the days clocks change, see DST dates.