Cron Expression Parser

Most cron explainers stop at "this runs every five minutes". That is the easy half. The half that causes real incidents is the calendar arithmetic: which day the job actually lands on, and what happens on the two days a year when the local clock is not a straight line. The workbench above computes the next ten real instants in the time zone you choose, using your browser's own IANA database, so you can read the answer instead of trusting a sentence.

Day of month OR day of week — not AND

When both the day-of-month and the day-of-week fields are restricted, POSIX cron combines them with OR. The expression 0 0 1 * 1 does not mean "the first of the month, but only when that day is a Monday". It means "the first of the month, and also every Monday". Over a single month that is four to six runs rather than one, which is usually the opposite of what the author intended.

This is the sharpest trap in the whole syntax, because the reading that feels natural — "day 1 and weekday 1" — is wrong, and nothing warns you. The tool adds a visible note whenever both fields are restricted, so the mismatch between the description and your intent is hard to miss. Watch what happens to the next-run list when you type 0 0 1 * 1 and hop between a Monday and the first of a month: both appear.

There is no way to express the AND you probably wanted in a five-field expression. The usual fixes are to move the condition into the job itself (run every Monday at midnight, then exit immediately unless the date is the first) or to use a scheduler whose syntax has separate "day of month" and "day of week" filters, such as a calendar expression in a workflow engine.

Daylight saving moves a run, or deletes it

A cron schedule is written in local wall-clock time, but a computer runs on absolute time. The two only agree until the clocks change. On the spring-forward transition the local clock jumps, for example from 02:00 straight to 03:00, so every minute in that gap is skipped for that date. A job set to 30 2 * * * simply does not run on the transition day: the time it wanted never existed. Pick America/New_York and step the expression to 30 2 * * * to watch 10 March 2024 disappear from the list while the surrounding days stay put.

The autumn transition is subtler. When the clock falls back, the hour between 01:00 and 02:00 happens twice. A naive scheduler keyed on wall-clock strings fires twice; classic cron fires once, at the first of the two instants. This tool takes the first occurrence, so the 3 November 2024 run of 30 1 * * * is reported once, at 05:30 UTC, not twice. If a schedule must fire a fixed number of times — billing, for instance — pin it to a zone with no transitions, or to UTC, and convert the display separately.

How the page works this out without a server

There is no offset table in the bundle and no lookup service. The search walks civil days forward one at a time and, for each candidate day, checks the month, the day-of-month and the weekday. For a matching day it takes the allowed hours and minutes in ascending order. To turn a wall-clock time into an absolute instant it asks Intl.DateTimeFormat what that zone's offset is at a first guess, corrects the guess with the answer, and repeats once so the correction has converged. If the final instant does not read back as the requested wall time, the time does not exist and the candidate is dropped — which is exactly how the spring-forward gap is detected.

You can verify the local-only claim in ten seconds. Open the network panel, clear it, and edit the expression: no request is made. Then switch the time zone back and forth; the run list changes because the browser's own database is being re-queried in memory, not because anything left the machine.

Checking a schedule before you ship it

Two habits catch most mistakes. First, confirm the description reads as the sentence you meant: if it mentions a weekday you did not intend, you have hit the OR rule. Second, confirm the first few run times fall on days and hours you recognise, in the zone the server will actually run in — a scheduler on a UTC host and a team reading local time is a classic source of "it ran at the wrong hour" tickets. When a job genuinely cannot run — day 30 of February, say — the tool says so plainly rather than printing an empty list that looks like a bug in the page.

Which time zone are the next-run times calculated in?

Whichever zone you pick in the Time zone dropdown. Nothing is inferred from a server, because there is no server: the page uses your browser’s own copy of the IANA time-zone database. Change the zone and every listed instant is recalculated immediately, including the ones that cross a daylight-saving transition.

Why is an expected run missing from the list?

Two reasons are common. First, the day-of-month and day-of-week fields are joined with OR, not AND, so an expression that looks like it targets one day may fire on many more. Second, on a spring-forward day the local wall clock jumps forward by an hour, and any scheduled time inside that gap does not exist, so the job is skipped for that occurrence. The tool shows the note whenever the first case applies.

Can I use a six-field expression with seconds, or @daily shortcuts?

No. This tool implements the classic five-field crontab layout used by Vixie cron, systemd timers and most hosted schedulers: minute, hour, day of month, month, day of week. Six-field variants that add a leading seconds column and the @daily / @weekly shortcuts are extensions; paste one here and the tool will tell you the field count is wrong rather than guessing.

What does "No matching time" mean?

The expression is syntactically valid but the fields can never line up, so it would never run. The clearest example is a day that does not exist in the month you restricted, such as day 30 of February. The tool scans roughly four years of future dates before reporting this, so it will not mistake a rare but real schedule — a leap-day job, for instance — for an impossible one.

Is my schedule sent anywhere?

No. Parsing, describing and the run-time search all happen in the page. Open the network panel and change the expression: no request carries it. The only third-party script on the site is the advertising tag, and it is not bound to the input.