Décoder une expression cron
Cron Expression Parser explains a schedule in English and lists its next ten runs, in your browser. It states the rule that catches almost everyone: when both day-of-month and day-of-week are restricted, cron ORs them — so 0 0 13 * 5 fires on the 13th or on any Friday, and is not Friday the 13th.
L’interface de cet outil est en anglais.
Le guide ci-dessous n’est disponible qu’en anglais.
How does Cron Expression Parser work?
Cron is five numbers and yet it is reliably misread. Three things account for almost all of it.
The two day fields are ORed, not ANDed
Every other pair of fields intersects: 0 9 * 6 * is nine o'clock in June, hour and month. The day fields do not. When both day-of-month and day-of-week are restricted, the job runs if either matches. So 0 0 13 * 5 fires on the 13th of every month and on every Friday — roughly five times a month, not once or twice a year. This is in POSIX and in Vixie cron's manual page and it still surprises people, which is why the explanation here spells it out rather than describing the fields separately.
When one of the two is *, the other decides alone, which is why 0 0 * * 5 is straightforwardly every Friday.
Next-run calculation is a search that must terminate
0 0 31 2 * asks for midnight on 31 February, which never happens. A minute-by-minute scan takes 2.6 million iterations to reach a one-year limit and give up; a scan with no limit never gives up at all. The search here skips by the largest unit it can rule out — a month that does not match advances to the first of the next month, not through its days — so an impossible schedule is proven impossible in a few hundred steps.
Everything here is UTC, deliberately
A cron job scheduled in a zone with daylight saving genuinely runs twice on one night a year and not at all on another: when the clock goes back, 01:30 happens twice; when it goes forward, 02:30 does not happen. Different cron implementations handle that differently, and some do not handle it at all. Computing in UTC and saying so is honest; silently applying your browser's zone would produce times that look authoritative and are wrong twice a year.
Field counts and dialects
Five fields is standard Unix cron. Six usually means seconds first, which is what Quartz, Spring and node-cron do — although a few schedulers put a year last instead, which is genuinely ambiguous and resolved here in favour of seconds. Seven fields is Quartz with both. The parser accepts month and day names, wrapping ranges like FRI-MON and 22-2, ? as a wildcard, both 0 and 7 for Sunday, and the @daily family of shorthands.
@reboot is recognised and explained rather than parsed: it has no schedule, so there is no next run to compute.
Expression
0 0 13 * 5
Explained
At 00:00, on day 13 of the month OR on Friday — cron ORs these two fields rather than intersecting them, so this is not "Friday the 13th". UTC.
What options and edge cases does Cron Expression Parser support?
| Parameter | Type | Default | Behaviour & edge cases |
|---|---|---|---|
| * | wildcard | every value | In a day field it also means 'let the other day field decide', which is what makes the OR rule tractable. |
| */n | step | — | Every nth value from the field's minimum. */15 in minutes is 0, 15, 30, 45 — not 'every 15 minutes from now'. |
| a-b | range | — | Inclusive. A wrapping range is accepted: 22-2 in hours is 22, 23, 0, 1, 2, and FRI-MON is the weekend. |
| a,b,c | list | — | Any mix of single values, ranges and steps, comma-separated. |
| n/m | step from n | — | 5/6 in hours is 5, 11, 17, 23 — from 5 to the maximum, in steps of 6. |
| Names | JAN-DEC, SUN-SAT | accepted | Case-insensitive, and usable in ranges: JAN-MAR, MON-FRI. |
| 0 and 7 | Sunday | both | Every implementation accepts both, and almost no documentation mentions it in the same place as anything else. |
| ? | wildcard | Quartz | Treated as *. Quartz uses it to mean 'no specific value' in a day field. |
| Field count | 5, 6 or 7 | 5 | Five is standard Unix. Six is read as seconds-first, which is what Quartz, Spring and node-cron mean. Seven is Quartz with a year. |
| @daily and friends | shorthand | expanded | @yearly @annually @monthly @weekly @daily @midnight @hourly. @reboot has no schedule and is explained rather than parsed. |
| Time zone | UTC | always | A local-time schedule genuinely runs twice on one night a year and not at all on another. Computing in UTC and saying so beats producing confidently wrong local times. |
Frequently asked questions
Does 0 0 13 * 5 run on Friday the 13th?
No — it runs on the 13th of every month and on every Friday. Cron ORs the two day fields rather than intersecting them, which is the opposite of what every other pair of fields does and the single most common cron misunderstanding. For Friday the 13th specifically, you need a day-of-month restriction plus a check inside the job itself; cron cannot express the intersection.
What does */15 actually mean?
Every value divisible by 15 within the field, starting from the field's minimum — so in minutes it is 0, 15, 30 and 45. It is not 'every fifteen minutes from when I deployed'. That distinction matters when you combine it with an hour restriction: 0 */2 * * * runs at 00:00, 02:00, 04:00 and so on, not two hours after each previous run.
Why are all the times UTC?
Because a local-time schedule is genuinely ambiguous twice a year. When the clock goes back, 01:30 occurs twice and some implementations run the job twice; when it goes forward, 02:30 does not occur and some implementations skip it entirely. Behaviour differs between cron implementations. Showing UTC and saying so is honest; quietly applying your browser's zone would produce authoritative-looking times that are wrong for two days a year.
Five, six or seven fields?
Five for Unix cron, crontab and most CI schedulers. Six for Quartz, Spring's @Scheduled and node-cron, where the extra field goes first and is seconds. Seven for Quartz with a year at the end. Six fields is genuinely ambiguous — a few schedulers put the year last instead — and this parser reads it as seconds-first, which is far more common.
Why does my expression show no runs?
It can never fire. The usual cause is a day-of-month and month combination that does not exist — 0 0 31 2 * asks for 31 February — or a year restriction already in the past. The search looks five years ahead before concluding this, so an empty list means genuinely impossible rather than merely distant.
Is my expression uploaded?
No. Parsing and the next-run search both run in your browser. A cron expression is not a secret, but it does describe your infrastructure's rhythm, and there is no reason for that to reach a server that has no use for it.