Cron expression explained, field by field, with the next run times

Read a cron expression

Type or paste an expression, or load a preset. Everything below updates as you type: the sentence, the expanded fields, the next run times and any problem with the expression itself.

The five fields

Read them left to right. Each one answers a single question about the local wall clock: which minute, which hour, which day of the month, which month, which day of the week. A run happens on a minute that satisfies all of them at once. The two day fields do not stack cleanly, which is why they get their own section below.

Months and days accept three-letter names in any case (JAN, jan, January), and 7 is an accepted spelling of Sunday in the day-of-week field alongside 0. Full names are accepted for readability, though three letters is the portable habit. There is no seconds field in cron: a schedule that needs one has to wrap the command, or move to a systemd timer.

Cron special characters

Four operators belong to Vixie cron, the implementation man 5 crontab documents and most servers run: *, -, , and /. The rest are Quartz extensions. Parsers disagree about which set they accept, so this table names the dialect rather than pretending the two are the same thing.

The Vixie behaviour worth memorising: a step always restarts at the bottom of the field's range, so */15 in the minute field is 0, 15, 30, 45 and never lines up with the previous run, while 0-59/15 is the same four values written explicitly. Steps compose with ranges and inside lists, so 1-5/2 is 1, 3, 5 and 0,30 is a two-value step-free list. A step of 0 is invalid rather than "every value": */0 would never advance past the start of the field.

The @ shorthands

One word instead of five fields. Every one of them except @reboot is exactly the entry in the second column, which is why a reader that expands fields explains them correctly.

@reboot is not a schedule. It runs once at boot, not on a schedule: cron starts the job when the daemon itself starts, which on most machines is boot, and never repeats it on a timer. It has no next run time, it does not wait for anything to come up, and it is the wrong hook for anything that must happen repeatedly. Its real use is starting a service the machine needs after boot; if you need ordering or a dependency, that is a systemd unit's job.

Day of month vs day of week: it is OR, not AND

This single rule causes more broken crontabs than anything else in the file, so it is worth stating plainly.

The Vixie specification says it in one line: if both fields are restricted (that is, neither contains the * character), the command will be run when either field matches the current time. So in 30 4 1,15 * 5, the job runs at 04:30 on the 1st and the 15th of every month and on every Friday — a union of about eight runs a month, not two. Set one of the two fields to * and the other one alone decides, which is what people almost always mean.

Quartz answers the same design problem differently: ? says "this day field carries no constraint" explicitly, which is why 5#3 and L always appear next to a ?. Vixie cron has no such marker and rejects ?, so the cleanest fix in a plain crontab is to delete one of the two day fields.

How to calculate the next cron run

And why the honest answer is usually "the next matching minute, found by walking forward".

cron has no next-run function to call. The daemon sleeps until the top of the next minute, reads the local clock and tests the five fields; if they all match, it forks the command. The next run is therefore the next minute that satisfies the expression, and the only way to know it is to search forward. The algorithm the reader above uses is the plain one: step one minute at a time, test the month first because it rejects the most candidates, then the hour, then the minute, then the two day fields with the either-or rule applied.

That search has to be capped, because some schedules can never match. 30 2 30 2 * asks for 02:30 on 30 February, and there is no such date in any year, leap or otherwise. An uncapped minute-by-minute walk never returns, so the reader stops after five years of days and reports the reason rather than freezing: it checks whether the largest day asked for can exist in any month the schedule names. The same trap has quieter versions — 0 0 31 2 *, or a day-of-month list that only ever asks for dates the chosen months do not have.

On a real machine, do not take a browser's word for it. systemd-analyze calendar '0 9 * * 1-5' prints the next elapses for a systemd calendar spec and tells you if the expression is nonsense. Debian's cron can validate a crontab file without installing it with crontab -T /tmp/test.crontab. To see what actually happened, read crontab -l for the entry and the syslog or journal for the daemon's own lines: Debian logs CRON[1234]: (user) CMD (command) at the moment each job starts. Note that cron does not stop a second run while the first is still going, so a slow job overlapping itself is a scheduling problem of its own.

Cron vs a systemd timer

Same job, different machine. On a host that already runs systemd, the timer is usually the better tool.

A systemd timer is the modern answer to the same problem and it is not a drop-in rewrite: OnCalendar= takes a calendar expression close to cron's (with seconds, which cron lacks), while OnUnitActiveSec= takes a real interval measured from the last activation. That difference matters more than it looks — a calendar timer repeats the same DST caveats cron has, while a monotonic timer cannot drift, cannot double across a clock change and cannot silently skip an hour. Persistent=true catches up a run missed while the machine was off, which plain cron never does, and AccuracySec= lets systemd batch several wake-ups into one instead of waking the machine every minute.

Neither one wins everywhere. cron is still the shortest path on a minimal VPS image, on macOS, on the BSDs, and whenever you want a schedule that reads the same on three different machines. A systemd timer is the better answer when the job is a unit with a lifecycle you want systemd to manage, when a missed run matters, or when the interval must survive a clock change.

Time zones and daylight saving

The part of cron that quietly breaks twice a year.

cron evaluates every entry in the server's local time — whatever /etc/localtime and the daemon's TZ say — and never in UTC. An entry has no timezone of its own, so the same crontab means different minutes in two offices. This reader assumes the same thing: it reads schedules as a naive wall clock, applies no timezone you did not type, and tells you which clock it used.

Across a DST transition the local clock moves, and cron follows it literally. In spring, an hour of local time does not exist, so a job scheduled inside that hour never arrives — not late, never. In autumn, an hour happens twice, so a job scheduled inside it can run twice. Implementations differ in the details, so treat both as unspecified behaviour and never put a job that must run exactly once on a boundary that moves. Two ways out: schedule in UTC (Debian's cron and cronie accept a CRON_TZ= line; systemd calendar timers take a UTC suffix), or use a monotonic systemd timer that does not care what the wall clock does.

Two more operational notes that belong in the same breath. Cron does not wait for a service to be up, so a job that depends on a database started at boot fails unless you make the dependency explicit. And cron's environment is minimal: SHELL, USER, HOME, LOGNAME, PATH and PWD, with PATH usually limited to a few directories — which is why the crontab generator above puts SHELL and PATH at the top of the block, and why full paths in commands are the habit that saves an afternoon.

Questions

Next to this one

Same desk, different job. All free, all in the browser.