Cron Syntax Explained, with Practical Examples

Cron’s five fields are easy to read and easy to get wrong. Here is how each field works, a table of schedules you can copy, the traps that make jobs run far too often or never, and what changes on GitHub Actions, Kubernetes and AWS.

By Deresaw Tools · Updated 3 October 2026

Cron is the scheduler built into Linux and macOS, and its five-field syntax is now used almost everywhere jobs run on a timer: CI pipelines, Kubernetes, cloud functions and countless libraries. A single line such as 30 2 * * * says “run at 02:30 every day”.

The syntax is short, which is why mistakes are easy to miss. A job meant to run hourly runs every minute; a job meant for the first Monday runs every day of the first week. This guide explains the fields, gives a table of tested examples, and covers the traps.

The five fields

A cron expression is five fields separated by spaces, always in this order:

┌───────── minute        (0–59)
│ ┌─────── hour          (0–23)
│ │ ┌───── day of month  (1–31)
│ │ │ ┌─── month         (1–12 or JAN–DEC)
│ │ │ │ ┌─ day of week   (0–7 or SUN–SAT; 0 and 7 are both Sunday)
│ │ │ │ │
* * * * *  command to run

A job runs when the current time matches every field (with one exception for the two day fields, explained below). Hours use the 24-hour clock, so 2 pm is 14.

The special characters

Many crontabs also accept shortcuts: @hourly (0 * * * *), @daily (0 0 * * *), @weekly (0 0 * * 0), @monthly (0 0 1 * *), @yearly (0 0 1 1 *) and @reboot, which runs once when the machine starts.

Practical examples

Each of these was checked in the Cron Expression Tester.

The traps

1. A step in the wrong field

*/5 means “every fifth value of this field“. In the minute field that is every 5 minutes. In the hour field, 0 */5 * * *, it is every 5 hours, and because the count restarts at midnight it runs at 00:00, 05:00, 10:00, 15:00 and 20:00, leaving a 4-hour gap before the next 00:00.

2. A star left in the minute field

* 9 * * * does not mean “at 9 o’clock”. It means every minute from 09:00 to 09:59: sixty runs. To run once at 09:00, write 0 9 * * *. Likewise 0 * 9 * * runs every hour on the 9th of the month, all 24 times.

3. Day of month and day of week together

This is the trap that catches experienced people. Every other pair of fields must both match. But when both the day-of-month and day-of-week fields are restricted, cron runs the job when either matches.

So 0 9 1-7 * 1, which looks like “09:00 on the first Monday of the month”, actually runs at 09:00 on each of days 1 to 7 and on every Monday. The tester shows this as “on day 1, 2, 3, 4, 5, 6 and 7 of the month or on Monday”.

The usual fix is to schedule by date and check the weekday in the command:

0 9 1-7 * * [ "$(date +\%u)" = "1" ] && /path/to/job.sh

4. The last day of the month

Standard cron has no “last day” value. 0 0 31 * * only runs in the seven months that have 31 days. A common workaround runs on days 28 to 31 and checks whether tomorrow is the 1st (this uses GNU date, as found on most Linux systems):

0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && /path/to/job.sh

5. The % sign

Inside a crontab, an unescaped % is treated as a newline, and everything after it is passed to the command as input. That silently breaks commands such as date +%Y-%m-%d. Escape each one as \%, as in the examples above, or move the command into a script.

6. Sunday is 0 and 7

Both mean Sunday in standard cron, and 1-5 is Monday to Friday. Some other schedulers (Quartz, AWS) number days 1 to 7 starting from Sunday, so 1 means Sunday there, not Monday.

Time zones and daylight saving

Cron uses the time zone of the machine or service it runs on. On servers that is very often UTC, so 0 9 * * * runs at 09:00 UTC, which might be 05:00 in New York or 14:30 in Delhi. The Cron Expression Tester shows every run in your local time and in UTC, and the Time Zone Converter helps you translate a target time into the server’s zone.

Daylight saving time causes two problems on machines that use local time. On the night the clocks go forward, times between about 01:00 and 03:00 may not exist. On the night they go back, an hour happens twice. Implementations deal with this differently: some run skipped jobs straight after the change, some skip them, some run repeated ones twice. To avoid surprises:

• Run servers on UTC, which has no daylight saving.
• Or avoid scheduling important local-time jobs between 01:00 and 03:00.
• Where the scheduler supports it, set the time zone explicitly (for example CRON_TZ in some crontabs, or timeZone in a Kubernetes CronJob).

How cron differs between platforms

The tester accepts the standard five-field form and the six-field form with seconds first, and tells you which it detected. It rejects Quartz-only characters like L and # rather than guessing what they mean.

Making cron jobs reliable

• Use absolute paths. Cron’s PATH is minimal, so python or node may not be found. Write /usr/bin/python3 /home/me/job.py.
• Log the output. By default cron emails output to the user or throws it away. Append >> /var/log/myjob.log 2>&1 so failures leave a trace.
• Prevent overlaps. If a job can take longer than its interval, two copies can run at once. On Linux, flock -n /tmp/myjob.lock /path/to/job.sh skips a run while the previous one is still going.
• Test the command by hand first, then check the next run times in the tester before saving the crontab.

Frequently asked questions

Tools used in this guide