What does a cron expression explainer do?
A cron expression explainer reads a schedule written in the shorthand cron has used since 1977 and says what it means in words. Each of the five fields lists values rather than naming a time: minute, hour, day of the month, month and day of the week, in that order. Between them they describe every moment the job should run, and the job fires whenever the current time matches all of them.
Reading one by eye is the easy part until it is not. A field can hold a single number, a comma-separated list, a range and a step, all in the same expression, so 0,30 9-17 * * MON-FRI is a great deal of information compressed into fifteen characters. The explainer unpacks each field separately, states what it means, and then joins those statements into one sentence about when the job actually runs.
The other half of the job is catching mistakes before they reach production. Values outside a field's range, an invalid step, a mistyped month name and an expression with the wrong number of fields are all reported rather than silently reinterpreted. And because the next firing times are computed properly, the one rule that surprises everybody — that a restricted day-of-month and a restricted day-of-week are combined with OR, not AND — becomes visible instead of hypothetical.
How to read a cron expression
- Paste the expression, or pick one of the examples to load it into the box.
- Check the field-by-field table: each row shows the raw value and what it means in words.
- Read the summary sentence underneath, which joins the fields into one statement of when the job runs.
- Heed the warning if both day fields are restricted — that is the OR rule, and it is the most common cause of a job that fires far more often than intended.
- Choose a starting point and read the next five firing times, which are computed in your local time zone.
- Fix anything the tool has flagged, which includes values out of range and month or weekday names it does not recognise.
Cron Expression Explainer limits and rules
| Item | Limit |
|---|---|
| Fields | Standard five, or six with a leading seconds field |
| Values in a field | Single numbers, lists, ranges and steps, and combinations of all four |
| Names | MON to SUN and JAN to DEC are accepted in the day-of-week and month fields |
| Shortcuts | @yearly, @monthly, @weekly, @daily, @hourly and @reboot |
| Next runs | The next five times, scanned minute by minute across roughly a year of minutes |
| Time zone | Your browser's local zone, which is usually the scheduler's own |
| Day rule | A restricted day-of-month and day-of-week are OR-ed, matching Vixie cron |
| Not covered | Quartz's year field, systemd OnCalendar syntax and non-standard extensions |
When to use it
- Checking a schedule you inherited in a crontab before trusting it with a backup or a bill.
- Working out whether */15 in the minute field means every quarter hour or something else.
- Confirming that a job meant to run on a specific weekday will not also fire on the matching date.
- Translating a schedule a colleague described in words into an expression you can paste in.
- Reading the next firing times to see whether a monthly job lands on a weekend.
Is it private?
The parsing and the next-run calculation happen in your browser: the expression is interpreted by JavaScript in this page and nothing is sent to a server, stored or logged.
Frequently asked questions
In order they are the minute, the hour, the day of the month, the month and the day of the week. A job runs at any moment where all five match the current time. The day of the month runs from 1 to 31 and the day of the week from 0 to 6 with Sunday as 0, though 7 is also accepted as Sunday in most implementations. Everything is evaluated against the scheduler's clock, not against an interval: cron does not schedule the next run relative to the last one.
Almost certainly the two day fields. When both day-of-month and day-of-week are restricted — that is, neither is a star — cron runs the job if either one matches, not if both do. An expression written to mean the first of the month only when it is a Monday actually means the first of the month, and also every Monday. That is standard behaviour, not a bug in a particular implementation, and the way round it is to leave one of the two fields as a star and test the other condition inside the command itself.
Every fifth value, starting from the beginning of the range, so minutes 0, 5, 10 and so on to 55. The star is the range — the whole field — and the slash introduces the step. In the minute field that gives twelve runs an hour; in the hour field */6 gives four runs a day. Writing 0/5 instead starts the count at the first value and behaves the same when the range begins at zero, which is why the two are often interchangeable in practice and not equivalent in principle.
No. The original Vixie cron uses five fields, and that is still what a crontab on a typical Linux system expects. A leading seconds field is an extension, and where it exists its position is not the only variation: Quartz puts seconds first and adds a year field of its own, while systemd uses a different notation entirely. Paste a six-field expression into an ordinary crontab and it will be rejected, so check which scheduler you are actually targeting before adding one.
Jobs run against local time, so a schedule fixed at 02:00 shifts by an hour when the clocks change, and in the spring a job set for a time that does not exist that day may fire late, twice or not at all depending on the implementation. If the exact moment matters — an invoice run, a settlement window — schedule in UTC and translate for display, rather than trusting a local-time schedule to hold steady twice a year.
Because cron is a family rather than a single specification. Vixie cron, the one you find in a traditional crontab, has five. Quartz, common in Java applications, uses six or seven and orders them differently — seconds and minutes first, then hours, day of month, month, day of week and an optional year. systemd timers abandon the format entirely in favour of OnCalendar, which is far more readable. The fields you have are a property of the scheduler, not of cron as a concept.
Related tools
Written and maintained by Md. Nur Hossain Repon.