Cron Expression Validator
Paste a cron expression and this validator checks that it's valid, explains each of its five fields in plain English, and lists the next five times it will run. */15 9-17 * * 1-5, for example, means every 15 minutes from 9:00 to 17:45 on weekdays.
Every 15 minutes during hour 9, 10, 11, 12, 13 and 4 more on Monday, Tuesday, Wednesday, Thursday and Friday.
*/15 9-17 * * 1-5Standard 5-field crontab syntax. Day of month and day of week are OR'd when both are set.
What the validator checks
Validation follows standard crontab rules. An expression is valid when:
- it has exactly five fields separated by spaces, or is one of the @ shortcuts such as @daily;
- each field uses only digits, three-letter month or day names, and the operators
*,-/; - every value is in range — minute 0–59, hour 0–23, day of month 1–31, month 1–12, day of week 0–6 (7 is also accepted as Sunday);
- ranges run from low to high, and steps are whole numbers above 0.
Under the hood, validating means parsing — which is why tools like this are also called cron parsers. The expression is split into its five fields, each field is expanded into the exact set of values it matches, and every value is checked against that field's range. Because each value is checked individually, the validator can name the exact value that's wrong instead of just rejecting the whole line.
Reading the result
The description sums up the whole schedule in one sentence. Under the input, five chips repeat each field's value: fields that restrict the schedule are highlighted in amber, and fields left as * stay grey, so you can see at a glance which parts of the expression actually do something. The run times on the right are calculated in your browser's timezone and refresh every 30 seconds. For a longer list and a count of how often the schedule fires, use the cron calculator.
Common errors and what they mean
| MESSAGE | CAUSE | FIX |
|---|---|---|
| Cron needs exactly 5 fields — this has 6. | A seconds or year field from another scheduler, or part of the command pasted along with the schedule. | Remove the extra field, or paste only the five schedule fields. |
| 60 is out of range (0–59) | Minutes run from 0 to 59 and hours from 0 to 23; there's no minute 60 or hour 24. | Use 0 and move on to the next hour or day. |
| range “17-9” runs backwards | Ranges have to go from low to high, even when they're meant to wrap around midnight. | Split it into two parts, such as 17-23,0-9. |
| step must be a number above 0 in “*/0” | A step of 0 would never move on to the next value. | Use a positive step, such as */5. |
| Couldn't read that one. | The input isn't five fields of numbers and cron operators — often a Quartz symbol like ?, L or # — so it was read as English. | Standard cron accepts only digits, names and * , - /; remove any other symbols. |
The day of month and day of week trap
The validator accepts 0 0 13 * 5, because it's valid — but it probably doesn't mean what its author intended. When both day fields are restricted, cron runs the job when either one matches, so this runs at midnight on the 13th of every month and on every Friday. The description spells it out (“on day 13 of the month and on Friday”), and the run times show both kinds of date, which is usually the quickest way to spot the mistake.
The cron format and syntax cheatsheet explains this rule and the rest of the syntax; to go the other way, from a description to an expression, use the cron expression generator.
Frequently asked questions
Does the cron validator support seconds?
No. It validates standard five-field cron, where the smallest unit is the minute. A six-field expression with seconds, as used by Quartz or Spring, is reported as having one field too many.
Are the validator's run times exact?
They're exact for your browser's timezone. If your server runs in a different timezone — often UTC — the job runs at the same clock times in that zone instead.
Is the expression I paste sent anywhere?
Not for validation: that and the run-time calculation happen entirely in your browser, and nothing you type is stored. If you've allowed analytics, pressing Copy on a valid expression records it in Google Analytics so we can see which schedules are used most; invalid input is never sent.
Why does the validator accept 7 as a day of week?
Most cron implementations accept 7 as a second number for Sunday, so the validator does too and treats it exactly like 0.