Cron Expression Builder

The five fields

The order is minute first, which is the opposite of how a time is written, and it is the single most common source of a schedule that fires at the wrong time entirely. `30 2 * * *` is half past two in the morning. `2 30 * * *` is impossible and will be refused.

*        every value          */15     every 15th, counting from 0
a        one value             5       minute 5
a-b      a range               9-17    hours 9 to 17 inclusive
a-b/n    a range, stepping     0-30/5  minutes 0, 5, 10 ... 30
a,b,c    a list                 0,30    minutes 0 and 30
?        same as *              -       Quartz and several hosted schedulers

Ranges that run backwards, like `22-2` for hours, are the one case where implementations differ. Vixie cron treats the range as wrapping, so it means 10pm to 2am. This page does the same and says so in the words, rather than quietly returning nothing.

The one that catches everyone: day-of-month OR day-of-week

When **both** the day-of-month and the day-of-week fields are restricted, cron does not require both to match. It requires **either**. Every implementation does this, and it has done so for decades.

0 0 13 * FRI

You probably meant:  the 13th, if it happens to be a Friday
It actually means: the 13th of every month, AND every Friday

In a month with five Fridays that is six runs, not one. The fix is to make one of the two fields a wildcard — `0 0 13 * *` for "the 13th" — or to accept that you meant both. This page implements the OR because that is what cron does, and says "either, not both" in the description, because a tool that silently "fixed" it would be generating a schedule that behaves differently from the one you are about to install.

Daylight saving, and the two answers

A cron schedule names a **wall-clock time** — 02:30, every day. Twice a year, in most of the world, 02:30 either does not happen or happens twice.

On a spring-forward day the clocks jump an hour forward, so the hour in between never arrives. On a fall-back day the clocks go back, so the hour before them arrives twice. Neither is an error in the expression. Both are a genuine question about what the job should do, and **cron implementations do not agree**.

So this page does not pick one silently. It defaults to **Vixie cron's behaviour**, because that is what most systems actually do, and it says so on the page rather than in a footnote. The alternative is one click away, and either way **every affected run is marked in the table**.

30 1 * * *      in Europe/Lisbon

On the autumn day the clocks go back at 02:00, so 01:30 happens
twice - once at +01:00 and once at +00:00. The job runs twice.
The table marks both.

On the spring day the clocks go forward at 01:00, so 01:30
never happens. Vixie skips it. The "shift forward" option runs
it at 02:00 instead, and the table shows both times.

The time zone is part of the schedule. `0 9 * * *` in `Europe/Lisbon` and in `America/New_York` are the same expression and different hours, and neither is wrong. This page defaults to UTC so the answer is the same for everyone reading it, and it tells you which zone it is showing you.

It also does not assume offsets are whole hours. Kathmandu is UTC+05:45 and Chatham is +12:45, and a scheduler that rounds to the hour is wrong in both — for Chatham, a 45-minute error twice a year when the clocks move.

29 February, and the century rule

`0 0 29 2 *` fires in leap years and not otherwise, which is occasionally useful and frequently a sign that you meant something else. The rule for what a leap year is has a part almost nobody remembers:

• Divisible by 4 — a leap year. 2024 is.
• **Unless** it is also divisible by 100. 1900 was not.
• **Unless** it is divisible by 400. 2000 was.

0 0 29 2 *

2028  2032  2036  2040  2044  2048  2052  2056  2060
2064  2068  2072  2076  2080  2084  2088  2092  2096
2100  <- divisible by 100 and not by 400, so no 29 February
2104  2108  2112  2116  2120  2124  2128  2132  2136

The 2100 gap is the reason a schedule written to run on 29 February will sit dormant for four years and then skip a year, with no error anywhere. There is a test in this project's suite for exactly that.

What the fields do not say

**The seconds.** Cron has no seconds field. `*/5 * * * *` means every five minutes past the hour, not every five seconds. If you need seconds you need a different scheduler, or a wrapper — and a surprising number of people write a five-field expression expecting six.

**How long the job may take.** Cron starts jobs on schedule. It does not wait for the last one, so a job that takes longer than its interval will overlap itself, and you will find out from the log rather than from cron. Every implementation has added some protection and none of them is a substitute for an idempotent job.

**Whether it is running at all.** An expression is a request, not a schedule. Nothing happens until the expression is in a crontab on a machine that is awake, and this page does not create one.

Checking an expression you did not write

The order that finds problems fastest, and it is not top to bottom:

• **The zone.** Get this wrong and every other answer is wrong in a way that looks right.
• **The OR.** If both day fields are restricted, count the runs per month. More than you expected is the OR, not a bug.
• **The hour the clocks move.** Look at the next spring-forward and fall-forward dates and see what this expression does on them.
• **Then the fields**, left to right, against the table above.

This page is built to answer the first three: it shows the zone, it spells out the OR, and it marks every run that daylight saving touches.

Doing it yourself

On a machine, `crontab -e` and nothing else. To see what an expression does without installing it, and to read what the system itself thinks:

crontab -l                      # what is installed
crontab -e                      # edit it

# check the syntax without saving - varies by implementation
crontab /tmp/check.cron || echo "rejected"

# what the system's own parser makes of it, with no ambiguity
# about the OR and no ambiguity about the zone
systemd-analyze calendar '30 2 * * *'

# and run it under a different zone, which is the other thing
# people forget to check
TZ=America/New_York systemd-analyze calendar '30 2 * * *'

In code, the same job in every language has a library, and the language's standard library is usually enough to check the arithmetic even if you do not want its parser. The two things worth doing yourself rather than trusting a library: know which DST policy you want, and know whether your day fields are about to be OR'd.