Cron expression parser

How the five fields are read

A standard cron line is five fields separated by spaces: minute (0–59), hour (0–23), day of month (1–31), month (1–12) and day of week (0–7, where both 0 and 7 mean Sunday). Each field takes a star for every value, a single number, a range such as 9-17, a comma-separated list such as 1,15,30, or a step such as */15. Steps also apply to ranges — 0-30/10 is 0, 10, 20 and 30 — and to a bare number, where 10/15 means from 10 onwards in fifteens until the field runs out.

Names are accepted in either case, so JAN to DEC and SUN to SAT work anywhere a number does: 0 9 * * MON-FRI and 0 9 * * 1-5 parse to exactly the same schedule. The shorthands @yearly, @annually, @monthly, @weekly, @daily, @midnight and @hourly are expanded first, and the table shows the five fields they became. @reboot is not a schedule at all — it is a trigger — so there is nothing to expand and nothing to predict.

The breakdown table is where most mistakes become visible. A field that matched one value when you expected a handful is usually a typo in a range; a step that does not divide its field evenly shows up as a list that restarts at the top of each hour instead of repeating cleanly.

The run list walks forward from the current minute, but it skips whole months, days and hours whose fields cannot match rather than testing every minute in turn. An expression that fires once a year is therefore found as quickly as one that fires every minute. The search stops after roughly four years, so an expression with no possible match reports that instead of spinning.

Questions people ask

Why does a job with both a day of month and a weekday run on both?

Because cron combines those two fields with OR rather than AND, and only when both of them are restricted. 0 0 13 * 5 fires at midnight on the 13th of every month and at midnight every Friday — about five times a month, not once every few months. The moment one of the two is a star the other one decides everything, so 0 0 13 * * is the 13th only and 0 0 * * 5 is Fridays only. It is documented behaviour inherited from Vixie cron and copied almost everywhere since, and it still catches people out. This parser follows the same rule, so the run list matches what your server will really do.

Does this handle six-field expressions with seconds?

No, and it says so rather than guessing. Quartz, Spring's scheduler, some Kubernetes tooling and several JavaScript libraries put seconds in a first field, which makes 0 */5 * * * * a five-minute schedule there and nonsense in classic cron. Paste six fields here and the error names the flavour you are probably using and asks you to drop the seconds. Deleting the leading 0 usually gives the equivalent five-field line — though anything that genuinely needs sub-minute precision has no five-field equivalent, because cron's smallest unit is the minute.

What time zone are the next runs shown in?

The expression itself is read as UTC, and each run is then shown twice: in the time zone your device is set to, with the zone name printed above the list, and in UTC underneath. So 0 9 * * 1-5 means nine in the morning UTC, which is why the local column may read 10:00 or 04:00 instead. Working in UTC means a daylight saving change cannot quietly shift the answer. Your own server is a separate question — most cron daemons run in the machine's local zone, so a job set for 02:30 runs twice or not at all on the two nights a year the clocks move. If that matters, put the machine or the crontab on UTC.

Is a step of five the same as writing out 0,5,10,15 and so on?

For minutes, yes — */5 expands to 0, 5, 10 … 55, and the two lines behave identically. That only holds while the step divides the field evenly. */7 gives 0, 7, 14 … 56 and then starts again at 0 in the next hour, so the gap between 56 and the following 0 is four minutes rather than seven. The same trap applies to */40 on minutes and to any step on the day-of-month field, where short months cut the cycle even further. For a genuinely even interval longer than an hour, put the step in the hour field instead.

Why does my expression say there are no runs in the next four years?

Because nothing can match it. The usual cause is a date the chosen month never has — 0 0 30 2 * asks for 30 February — or a day-of-month value above the length of every month you selected. The four-year cap exists so that a hopeless expression cannot lock the tab up while it searches. It also means genuinely rare schedules show a short list: 0 0 29 2 * finds the next leap day, but usually not the one after it.

Is anything I paste sent to a server?

No. This page is static HTML, a stylesheet and one small script; after it loads there is no request of any kind, no cookie and no local storage recording what you typed. Cron lines are usually harmless on their own, but the command sitting next to them in a crontab often contains a host name, a database user or a token, and those get pasted by accident. Open your browser's network panel and type into the box — nothing leaves. Once the page has loaded you can disconnect completely and it carries on working.