Cron Expression Generator

How to use the cron expression generator

There are two ways in, and they drive the same state. To generate an expression, work through the five field blocks: pick whether each field means every value, an interval, a set of specific values, or a range, and the expression above updates as you go. To translate an expression you already have — from an inherited crontab, a CI config, or a colleague — paste it into the expression box instead. The builder fills itself in, the plain-English line tells you what it actually means, and the next-run list shows the real dates it will fire.

Either way, check the upcoming run times before you commit the schedule — that list is the fastest way to catch an expression that parses cleanly but fires at the wrong moment. Nothing you type leaves your browser.

Cron expression format

A cron expression is five space-separated fields. Each one answers a single question about when the job runs, and they are always in this order:

The job runs when the minute, hour and month fields all match the current time and at least one of the two day fields matches. So 0 3 * * 1-5 is minute 0, hour 3, any day of the month, any month, Monday through Friday — 3:00 AM on weekdays.

An expression is not the same thing as a crontab line. A crontab entry is the schedule plus the command: 0 3 * * 1-5 /path/to/backup.sh. The generator shows both, because on its own the expression does nothing.

Cron special characters

Four characters cover everything standard cron can express:

These combine freely on Linux: 0-30/10,45 is valid, and so is 8-18/2. Two things about steps catch people out. First, a step is evaluated only inside its own field — */23 in the hour field means hour 0 and hour 23, not "every 23 hours", because there is nothing to carry the remainder into the next day. Second, a step that does not divide its field evenly restarts at the boundary, so */7 in the minute field fires at :00, :07 … :56 and then again at :00 four minutes later. Any interval that does not divide 60 — every 90 minutes, for example — needs two crontab lines rather than one clever expression.

The @ shorthands — @daily, @hourly, @weekly, @monthly, @yearly, @reboot — work on Linux, and pasting one in here expands it to the five-field equivalent. @reboot is the odd one out: it has no calendar schedule, and it fires when the cron daemon starts, which is not always a machine boot. Worth knowing that steps, the shorthands and three-letter names are all Vixie cron extensions rather than original POSIX syntax, which only has *, values, lists and ranges — relevant only if you are targeting an unusual Unix.

Common cron schedules

A scheduled script has to be executable and has to work with cron's very short PATH, so use absolute paths inside it — our chmod calculator and the guide to running a shell script cover the permissions side, and set -e can exit after some command failures, but explicit error handling is still important. For the command half of the line, rsync and disk-space checks are the two most commonly scheduled tasks.

Day of week: 0, 7 and names

Sunday can be written as either 0 or 7, because Linux cron accepts both. The original POSIX range is 0-6 with 0 as Sunday, and 7 was added by Vixie cron for the people who expected the week to end rather than start on Sunday. Three-letter names work too — 0 0 * * SUN and 0 0 * * 0 are the same schedule.

The duality has one sharp edge: 1-7 is not a tidy "Monday to Sunday" — it covers all seven days, because 7 folds back onto Sunday alongside 1 through 6. This generator accepts 7 and names on input but always writes numbers with Sunday as 0. Named ranges like mon-fri show why: cronie accepts them, Debian's cron historically did not, so numbers are the portable choice.

When day-of-month and day-of-week are both set

This is the single most misunderstood rule in cron, and it is worth reading carefully. When both day fields are restricted, cron runs the job when either one matches. They are combined with OR, not AND.

The generator flags this whenever you restrict both fields, and the next-run list shows the real union, so you can see the extra dates rather than discovering them in production. To pin a single day, restrict one field and leave the other as *. Cron genuinely cannot express "the nth weekday of the month" on its own — the standard workaround is to schedule the wider window and let the command bail out early:

Note that the month field is not part of the OR rule. It always has to match, so 0 0 1,15 6 1 only ever runs in June.

Time zones and daylight saving

Cron expressions contain no time zone. A job runs when the clock on the machine running the cron daemon matches the expression, so 0 9 * * * is 09:00 UTC on a server set to UTC — which most cloud images are — and 09:00 local time on a server set to something else. The daemon runs with one configured zone and classic Debian cron has no per-user time zones; setting TZ in a crontab affects the environment the command runs in, not when it is scheduled. cronie, the cron on RHEL and Fedora, does honour a CRON_TZ= line, but that is not portable.

Daylight saving is the reason to care. On a server in a DST-observing zone the hour skipped each spring can mean a job inside it never runs that day, and the hour repeated in autumn can mean it runs twice. Behaviour varies between cron implementations, so there is no portable answer — keep servers on UTC, or avoid scheduling anything critical between 01:00 and 03:00. To confirm a job actually ran, journalctl and systemctl status are where to look.

What cron cannot express

Some schedules are simply outside the syntax, and no generator can produce them:

• Anything under a minute. There is no seconds field in Unix cron. "Every 30 seconds" needs a loop with sleep, or a systemd timer.
• "Every N days from now." */3 in the day-of-month field restarts each month, so the gap across a month boundary is not three days.
• The nth weekday of a month. Quartz has # for this; crontab does not.
• Intervals that do not divide their field — every 90 minutes, every 7 hours. These need more than one line.

If you are working with ?, L, W, #, a leading seconds field or a trailing year field, you have a Quartz or AWS EventBridge expression rather than a crontab one. They are different dialects, not extensions — pasting a six-field expression into a crontab will fail to install. For schedules that are genuinely too calendar-complex for cron, systemd timers and their OnCalendar= syntax are the usual Linux answer.

FAQ