Validate any five-field expression and see the next runs with the Cron Expression Builder — local time and UTC, entirely in your browser.
Why cron still runs the world
Backups, certificate renewals, report generation, database cleanups — the quiet jobs that keep systems healthy are usually scheduled with cron.
The syntax is compact, which makes it fast to write and easy to get subtly wrong. A single wrong field can mean a job runs 60 times a day instead of once, or never runs at all.
The good news: the format is small enough to learn completely, and the next-run preview makes mistakes visible before they reach production.
The five fields
A standard cron expression has five fields separated by spaces, in this order:
| Field | Range | Example |
|---|---|---|
| Minute | 0-59 | */15 |
| Hour | 0-23 | 9 |
| Day of Month | 1-31 | 1 |
| Month | 1-12 | 3,6 |
| Day of Week | 0-6 (0 = Sunday) | 1 |
Steps, ranges, and lists
Each field accepts more than a single number:
`*/5` steps through every fifth value. `9-17` selects a range. `9-17/2` steps inside a range. `1,15` lists individual values, and lists can combine ranges like `1-5,10`.
These compose into schedules you can actually read: `0 9-17/2 * * 1-5` runs at 09:00, 11:00, 13:00, 15:00, and 17:00 on weekdays.
- `*` — every value
- `*/n` — every nth value
- `a-b` — inclusive range
- `a-b/n` — range with a step
- `a,b,c` — list of values
The day-of-month and day-of-week trap
When both day-of-month and day-of-week are restricted, cron implementations disagree. POSIX defines the result as the union (OR) of the two fields; the Vixie cron used on many Linux systems treats them as an intersection (AND).
The same expression can therefore run on different days on different systems. Always check the documented behavior of your target scheduler — and preview the next runs on that system, not on a website with different semantics.
Warning: An expression like `0 0 1 * 1` may run on the first of every month, every Monday, or only when the first is a Monday, depending on the cron implementation. Verify before deploying.
A safe schedule workflow
- Write the expression, or start from a preset like every 15 minutes.
- Review the field breakdown to confirm minute, hour, day, month, and weekday values.
- Read the next five run times in local time and UTC.
- Check the day-of-week semantics of your target system when both day fields are restricted.
- Copy the verified expression into your scheduler and monitor the first few runs.
FAQ
Q.What does 0 9 * * 1 mean?
A.Minute 0, hour 9, any day of month, any month, and day of week 1 (Monday): 09:00 every Monday. Sunday is 0, and 7 is accepted as an alias for Sunday.
Q.Is my schedule uploaded when I validate it?
A.No. The expression is parsed and the next runs are computed in your browser. Nothing leaves your device.
Q.Should I use UTC or local time in cron?
A.Most servers run cron in the system time zone, which is often UTC in containerized or CI environments. Preview both and confirm which time zone your scheduler uses.
References
This guide follows the common five-field format and related specifications:
- The Open Group Base Specifications – crontab: https://pubs.opengroup.org/onlinepubs/9799919799/utilities/crontab.html
- Vixie cron man page (day-of-month/day-of-week semantics): https://man7.org/linux/man-pages/man5/crontab.5.html
- RFC 5545 – Internet Calendaring and Scheduling (recurring rules as a related concept): https://www.rfc-editor.org/rfc/rfc5545
Validate a schedule now
Five fields, next-run previews, and UTC/local time — entirely in your browser.
Preview before you deploy
Cron bugs are cheap to catch and expensive to discover: a report that never ran, a backup that missed its window, a job that hammered the database every minute.
Validate the expression and read the next runs with the Cron Expression Builder before you touch production.