Cron Format & Syntax Cheatsheet

┌───────────── 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 Sunday)
│ │ │ │ │
* * * * *  command to run

The cron format: five fields

The format dates back to the original Unix cron, and Vixie cron, cronie, Kubernetes CronJobs and GitHub Actions all read it the same way. The fields always come in this order, from the smallest unit of time to the largest, with the day of week last:

Operators

Four symbols cover every standard schedule, and they can be combined within a field.

A step always counts from the start of its range: */15 is shorthand for 0-59/15, and 10-50/20 gives 10, 30 and 50. Combining operators works too — 0 9-17/2 * * 1-5 runs at 9, 11, 13, 15 and 17 o'clock on weekdays.

Field by field

How day of month and day of week combine

The two day fields follow a special rule. If either one starts with * — plain *, or a step such as */2 — a day has to match both. If neither starts with *, cron runs the job on days that match either field. So 0 0 13 * 5 runs at midnight on the 13th of every month and on every Friday, not only on Friday the 13th, while 0 0 */2 * 1 runs only on odd-numbered days that are also Mondays.

To require both — “the first Monday”, “Friday the 13th” — restrict one field in the expression and check the other inside the command. The every Monday and every Friday pages show the pattern.

Special strings

Most crons accept these shortcuts in place of the five fields:

Writing a crontab line

A crontab line is the five fields followed by the command:

# m  h  dom mon dow  command
  30 2  *   *   *    /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1

• crontab -e edits your own crontab and crontab -l lists it.
• System files — /etc/crontab and the files in /etc/cron.d/ — have an extra field naming the user to run as, between the schedule and the command.
• Jobs run with a minimal environment; PATH is often just /usr/bin:/bin. Use absolute paths, or set PATH= at the top of the crontab.
• A % in the command is turned into a newline, so escape it as \\% — for example in date +\\%F.
• Output is emailed to the crontab's owner, or to the address in MAILTO=, if the machine can send mail. Redirect it to a file to keep a log.

Non-standard syntax you might see

Other schedulers extend cron's syntax. None of these work in a standard crontab:

• A seconds field at the front — Quartz, Spring and several libraries use six or seven fields.
• ? for “no specific value” in one of the day fields — Quartz and AWS EventBridge require it.
• L for the last day of the month, W for the nearest weekday, and # for the nth weekday (6#3 is the third Friday in Quartz, where Sunday is 1).
• H in Jenkins, which picks a consistent pseudo-random value per job so that H * * * * spreads hourly jobs across the hour.

Common mistakes

• * 2 * * * runs every minute from 02:00 to 02:59 — sixty times. For once at 2am, write 0 2 * * *.
• Restricting both day fields and expecting AND: 0 0 1-7 * 1 isn't “the first Monday”.
• Scheduling on the 29th, 30th or 31st and expecting a run every month.
• Writing 24 for midnight — the hour field stops at 23.
• Forgetting that times are in the server's timezone, which is often UTC.

To check an expression against all of this, paste it into the cron expression validator, or browse the examples for ready-made schedules.