How to Write a Cron Expression: Five Fields and the OR Rule Nobody Mentions

Five fields, and a step is not an interval

Read the fields left to right and the notation is small enough to hold in your head. An asterisk stands for the whole range of its field. A hyphen makes an inclusive range, so 8-11 in the hour field is four hours, not three. A comma makes a list, and lists and ranges combine freely in the same field, so 1-3,7-9 is a legal set of six values. Names may replace numbers in the month and day-of-week fields using the first three letters, though classic Vixie cron will not accept a range or a list built from names — 1-3 parses where JAN-MAR may not, which is a good reason to stick to numbers in anything portable.

The slash is where the mental model usually breaks. A step is a stride through a range, not a repeat interval, and the range restarts at the top of every parent unit. In the minute field */15 walks 0, 15, 30, 45 and then the hour rolls over and it starts again at 0 — which happens to be every fifteen minutes, so nobody notices the distinction. Write */40 and the illusion collapses: it walks 0 and 40, then the hour rolls over and it starts again at 0, giving gaps of forty minutes and then twenty. The same applies to a bounded range: 0-23/2 in the hour field is the even hours, and 1-9/2 is 1, 3, 5, 7 and 9. If you actually need an interval that does not divide its unit evenly, cron cannot express it in one line and you need two entries or a guard inside the command.

The two day fields are combined with OR, not AND

This is the rule most explainers get wrong, and it is not a quirk of one implementation — it is written into the specification. POSIX states that if the day of month is given as an element or list and the day of week is also given as an element or list, then any day matching either the day of month or the day of week shall be matched. The crontab(5) manual says the same thing in plainer words and gives the canonical example: 30 4 1,15 * 5 runs at 4:30 in the morning on the 1st and the 15th of each month, plus every Friday. Not the 1st or 15th when they happen to fall on a Friday. Both sets, unioned.

The practical rules that follow are short. If exactly one of the two day fields is an asterisk, the other one governs and there is no ambiguity — this is the case you should write almost every time. If both are asterisks, every day matches, which is also unambiguous. Only when both are restricted does the union kick in, and the result is almost never what the author intended: 0 0 1 * 1 fires roughly five times a month rather than once. There is no cron syntax for the intersection, so if you genuinely need the first Monday of the month, the standard trick is to schedule the union and then narrow it inside the command — run it on 0 0 1-7 * 1 and open the script with a test that the current day of week is Monday, or on 0 0 * * 1 with a test that the day of month is 7 or less. Quartz-style crons add a # operator for this, but it is not available to system cron.

Everything past the five fields is implementation-specific

POSIX defines five fields, the asterisk, ranges, lists and nothing else. Every convenience you have seen beyond that is an extension, and extensions vary. The slash step is a Vixie extension that is now near-universal but is still not in the standard. The shorthand strings — @yearly and its synonym @annually, @monthly, @weekly, @daily and its synonym @midnight, @hourly, and @reboot — come from the same lineage, and @reboot in particular has no fixed meaning across systems because what counts as a reboot depends on the daemon. A sixth field for seconds is common in application-level schedulers such as Quartz, Spring and several Node libraries, and absent from system cron, so an expression copied from a framework's documentation into a crontab will be off by one field and will schedule something entirely different rather than failing loudly.

The question mark belongs to the same family. In Quartz it means no specific value and exists precisely to resolve the day-of-month versus day-of-week ambiguity by declaring one field irrelevant; system cron does not accept it at all. The L, W and # operators for last day of month, nearest weekday and nth weekday are likewise Quartz-only. Two more environmental facts matter more than any of this syntax: the daemon runs jobs in the timezone it is configured for, so an expression that is correct in one deployment can fire an hour early or late in another, and around a daylight-saving transition a job scheduled in the skipped hour may not run at all while one in the repeated hour may run twice. And cron is a trigger, not a job runner — it has no retries, no concurrency control and no memory that the last run failed. If two invocations must not overlap, take a lock inside the command yourself.

Frequently asked questions

What exactly does */15 mean?

In the minute field it selects the values 0, 15, 30 and 45 — a stride of fifteen through the range 0 to 59, starting at the range's first value. It is not a timer that fires fifteen minutes after whenever it last ran, and it does not survive an unclean division: */40 in the minute field selects only 0 and 40, so the gaps are forty minutes and then twenty as the next hour restarts the range. If you want an interval measured from the last run rather than from the top of the hour, cron is the wrong tool and a systemd timer with OnUnitActiveSec, or a loop inside a long-lived process, is the right one.

How do I run a job every 90 minutes?

Not in one line, because 90 does not divide 60 and a step is confined to a single field. The pattern does repeat every three hours, though, so two entries cover it exactly: 0 */3 * * * gives you 00:00, 03:00, 06:00 and so on, and 30 1-23/3 * * * gives you 01:30, 04:30, 07:30 and so on. Together they produce a run every ninety minutes, and the sequence wraps cleanly at midnight because twenty-four hours is exactly sixteen ninety-minute intervals. The same two-entry trick works for any interval that divides evenly into a whole number of hours; anything that does not, such as every 50 minutes, cannot be expressed in cron at all.

Why did my nightly job run twice, or not at all?

The usual cause is a daylight-saving transition. Cron matches wall-clock time, so when the clock jumps forward an hour that never existed is never matched and a job scheduled inside it simply does not run; when the clock falls back, an hour occurs twice and a job scheduled inside it can fire twice. Implementations differ in how hard they try to compensate, which is why the same crontab behaves differently on two distributions. The reliable fixes are to schedule sensitive jobs outside the transition window, to run the daemon in a timezone that has no transitions, or to make the command itself safe to run twice. That last one is worth doing regardless: idempotence protects you from retries, overlapping runs and manual re-execution as well.