Cron Expression Parser
Turn a cron expression into plain English — and check it is valid.
This schedule runs
At 09:00 on Monday, Tuesday, Wednesday, Thursday and Friday.
| Field | Value | Matches |
|---|---|---|
| minute | 0 | 0 |
| hour | 9 | 9 |
| day of month | * | every value |
| month | * | every value |
| day of week | 1-5 | 1, 2, 3, 4, 5 |
Reads the five-field crontab format: minute, hour, day of month, month, day of week. Names such as MON or JAN and step syntax like */15 are supported. Note that when both day of month and day of week are restricted, cron runs on either match, not both.
Paste a cron expression and get it translated into plain English — 'At 2:30 AM, every day' instead of '30 2 * * *' — along with validation to catch typos before a scheduled job silently runs at the wrong time.
Cron syntax is compact but easy to misread, especially the difference between day-of-month and day-of-week fields, which this tool spells out explicitly.
The five fields
| Position | Field | Range | Special values |
|---|---|---|---|
| 1 | Minute | 0–59 | * , - / |
| 2 | Hour | 0–23 | * , - / |
| 3 | Day of month | 1–31 | * , - / L W |
| 4 | Month | 1–12 or JAN–DEC | * , - / |
| 5 | Day of week | 0–7 (0 and 7 are Sunday) | * , - / L # |
L, W and # are extensions supported by Quartz and some other schedulers, not by standard Unix cron.
Patterns you'll actually use
| Expression | Runs |
|---|---|
| */5 * * * * | Every 5 minutes |
| 0 * * * * | Every hour, on the hour |
| 0 2 * * * | Daily at 02:00 |
| 0 2 * * 1 | Every Monday at 02:00 |
| 0 2 1 * * | The 1st of each month at 02:00 |
| 0 9-17 * * 1-5 | Hourly, 09:00–17:00, weekdays |
| 30 3 * * 0 | Sundays at 03:30 |
| 0 0 1 1 * | Once a year, midnight on 1 January |
The day-of-month / day-of-week trap
If both field 3 and field 5 are set to something other than *, most cron implementations run the job when either matches — an OR, not an AND. So `0 0 13 * 5` runs on the 13th of every month and on every Friday, not only on Friday the 13th.
This surprises nearly everyone the first time. If you need both conditions, set one field to * and check the other condition inside your script.
- Cron runs in the server's time zone unless you configure otherwise — a job at 02:00 may run twice or not at all on DST transition days.
- Schedule sensitive jobs outside the 01:00–03:00 window where clock changes happen.
- Cron does not guarantee a job won't overlap with its previous run. If a job can run long, add your own locking.
- Test with a parser before deploying. A typo in field 3 that should have been field 5 is silent and can go unnoticed for a month.
Frequently asked questions
- What do the five fields in a cron expression mean?
- In order: minute, hour, day-of-month, month, and day-of-week. Each can be a specific value, a range, a step (like */5), or an asterisk meaning 'every'.
- Why does my job run on days I didn't expect?
- When both day-of-month and day-of-week are set to something other than *, most cron implementations treat them as an OR condition — the job runs if either matches, not only when both match.
- Can this validate whether my cron expression is syntactically correct?
- Yes — invalid field values or malformed expressions are flagged clearly, rather than silently parsed into something unintended.
- How do I run a job every 90 minutes?
- You can't express it in a single standard cron line, because the minute field restarts each hour. Use two entries, or schedule hourly and skip alternate runs in your script.
- What happens to a job scheduled during a daylight saving change?
- It depends on the implementation, but a job at 02:30 may be skipped in spring and run twice in autumn. Schedule anything important outside that window, or run the server in UTC.
- Is 0 the same as 7 for Sunday?
- In most implementations yes — both mean Sunday, for compatibility between conventions. Some schedulers use 1–7 with 1 as Monday, so check your platform's documentation.