Cron Expression Generator and Explainer

The OR rule: why 0 12 13 * 5 is not Friday the 13th

Four of the five cron fields are combined with AND. Minute, hour and month all have to match at once, exactly as you would expect. The two day fields are the exception, and the rule is inverted: when day-of-month and day-of-week are both restricted — meaning neither is * — the job runs whenever either one matches. This is not a quirk of one implementation. It is written into the POSIX specification for crontab and repeated in the crontab(5) manual page on Linux and macOS.

So the expression that looks like it means “noon on Friday the 13th” means “noon on every 13th, and also noon on every Friday”. Here is September 2026, which has four Fridays and a 13th that falls on a Sunday:

Note the Sunday in the middle. That is the 13th matching on its own, with the weekday field ignored for that day.

Stretched over a year the gap is brutal. In 2027 there are 53 Fridays and 12 thirteenths, overlapping exactly once — Friday 13 August 2027. A real Friday-the-13th job should run once. 0 12 13 * 5 runs 64 times. If that job sends an email, bills a customer, or posts to a channel, you find out the expensive way.

The tool above implements this rule rather than pretending it does not exist: when both day fields are restricted, the next-run list uses OR, the plain-English sentence spells out “cron matches either day rule, not both”, and an amber warning appears under the field breakdown. Try pasting 0 12 13 * 5 and watch a Sunday appear in a list of Fridays.

How to actually schedule Friday the 13th

You cannot, in the five fields alone — the OR rule makes the intersection unexpressible. The standard workaround is to schedule on one day field and enforce the other inside the script: run it with 0 12 13 * * and have the command exit immediately unless the weekday is Friday, for example a first line of [ "$(date +\%u)" = "5" ] || exit 0. The backslash matters: inside a crontab a bare % is treated as a newline, so every percent sign in a command has to be escaped. The same guard pattern covers “first Monday of the month” and every other rule cron cannot express on its own.

And the simple prevention: restrict at most one day field. If day-of-week carries the meaning, leave day-of-month as *, and the other way round. The moment both are anything other than *, you are in OR territory whether you meant to be or not.

The five fields, position by position

Fields are separated by whitespace and their meaning comes entirely from their position. Miscount by one and the expression is still valid — it just runs at the wrong time, which is why a five-field expression that “works” is not the same as one that is right.

Two details in that last row do real damage. First, 0 and 7 both mean Sunday, so the range is 0–7 rather than 0–6 and 0 0 * * 0 and 0 0 * * 7 are identical schedules. Paste both into the tool and the next-run lists match exactly. Second, day names are accepted but ranges of names behave like ranges of numbers, so FRI-SUN reads as 5 to 0, which runs backwards and is rejected — write FRI,SAT,SUN or 5,6,0 instead.

A dozen schedules worth copying

Every expression here was checked against the tool’s own next-run engine, and the English column describes what actually fires rather than what the expression looks like it should do.

Shorthands like @daily, @weekly and @reboot are crontab conveniences rather than field expressions, so they are not something this tool parses. @daily is exactly 0 0 * * *; @reboot has no clock equivalent at all.

What */n really means, and where the gap goes

The near-universal misreading is that */15 means “every 15 minutes from whenever the job last ran”. It does not. A step selects every n-th value counting from the start of the field, and the count restarts at each field boundary. For minutes, which run 0 to 59, */15 expands to 0, 15, 30 and 45 — exactly what you wanted, but only because 15 divides 60.

Pick a step that does not divide evenly and the interval is no longer the interval. */25 * * * * fires at :00, :25 and :50 — then the hour resets, so the fourth gap is 10 minutes, not 25. */40 * * * * is worse: :00, :40, then 20 minutes later it is :00 again. 0 */5 * * * gives you 00:00, 05:00, 10:00, 15:00, 20:00 and then a four-hour hole across midnight. And 0 0 */2 * * means the 1st, 3rd, 5th and so on — so a 31-day month is followed by the 1st of the next one, and the job runs on two consecutive days at the turn of the month.

A step can also be anchored. 0 8-18/2 * * * counts in twos from 8, giving 08:00 through 18:00, and 0 9/3 * * * counts in threes from 9 to the end of the field: 09:00, 12:00, 15:00, 18:00 and 21:00. If the interval genuinely matters — a lock renewal, a heartbeat — anchor the range rather than trusting */n to be even.

The clock cron uses is not your clock

A cron expression carries no timezone. It is evaluated in the timezone of the machine running the daemon, which on cloud servers and inside most container images is UTC. A schedule you wrote as “9am” in London fires at 9am UTC, which is 10am local for half the year — and for a team in New York the same line is a 4am or 5am job. Run date on the actual host before you trust an hour. The next-run list in the tool above is computed in your browser’s timezone and prints which one that is, precisely so you can see the difference rather than assume it away.

If the server is not on UTC, daylight saving becomes a scheduling problem. Take 30 2 * * *, a daily 02:30 job — a very common slot, because it is quiet. In a US or European timezone, the spring-forward night has no 02:30 at all: the clock jumps from 01:59:59 to 03:00:00. On the autumn night, 02:30 happens twice.

What happens then depends on the implementation, and this is where portability dies. The Vixie-derived cron shipped by Debian and Ubuntu documents its behaviour in cron(8): for a clock change of less than three hours, fixed-time jobs skipped by a forward jump are run shortly after the change, and jobs falling inside a repeated hour are not run a second time — and this applies only to jobs at a particular time, not to ones with * in the hour or minute. Other schedulers make different choices, and some simply miss the run or fire it twice. If a job must not double-fire, do not rely on the daemon: make the job idempotent, or move the host to UTC and do the timezone arithmetic yourself.

The practical rule is boring and works: keep servers on UTC, keep expressions in UTC, and translate for humans in the documentation. If a job genuinely has to land at a local wall-clock time — a report that must arrive before the office opens — use a scheduler that takes an explicit timezone rather than encoding your guess about the offset into the hour field.

Six fields means you are in a different dialect

“Cron syntax” is a family, not a standard, and the differences are silent until something fires at the wrong time. This tool parses standard 5-field Unix cron — the Vixie and cronie crontabs on Linux and macOS. If your expression has six or seven fields, it belongs to a relative:

• A leading seconds column. Spring’s @Scheduled and several Node schedulers put seconds first, so a six-field expression is usually just yours with a seconds field bolted on. Drop the first column to get the 5-field equivalent.
• Quartz. Seconds first, an optional trailing year, and extra characters — ? for “no specific value”, L for last, W for nearest weekday, # for “n-th weekday of the month”. Crucially its day-of-week runs 1–7 with 1 meaning Sunday, so a bare 5 is Friday in Unix cron and Thursday in Quartz. Quartz also sidesteps the OR problem by refusing to let you specify both day fields — one of them must be ?.
• AWS EventBridge. Six fields with a year, evaluated in UTC unless you set a timezone, and it borrows the Quartz rule that one day field must be ?.
• GitHub Actions. Ordinary 5-field cron, always UTC, and scheduled runs can be delayed or dropped under load — treat the time as a hint, not a guarantee.
• Kubernetes CronJob. Standard 5-field syntax, and it inherits the OR rule exactly as described above. It runs in the controller’s timezone unless the CronJob sets one explicitly.

Rather than guess, the tool refuses. A six-field expression is flagged as such, and ?, L, W and # are named as Quartz extensions instead of being quietly ignored — a wrong answer delivered confidently is worse than no answer. Everything happens in your browser: nothing you type is uploaded, and there is no account, no saving and no history.

Frequently asked questions