Cron and crontab syntax, explained

Crontab format: one job per line

A crontab is a plain text file with one job per line: the five schedule fields, then the command to run. Everything after the fifth field, to the end of the line, is the command. Cron also reads comment lines, blank lines and variable settings, so a typical crontab looks like this:

# Variables apply to the jobs below them
SHELL=/bin/bash
PATH=/usr/local/bin:/usr/bin:/bin
MAILTO=ops@example.com

# m h dom mon dow command
*/5 * * * * /usr/local/bin/check-queue
30 2 * * 0 /usr/local/bin/backup.sh >> /var/log/backup.log 2>&1
@reboot /usr/local/bin/start-worker

The last line needs a line break after it, or crontab refuses the file with “new crontab file is missing newline before EOF”. To install or change a crontab, see how to edit crontab.

Days of the week in cron

The fifth field is the day of the week. Cron counts from Sunday as 0, so Monday is 1 and Saturday is 6, and most crons also accept 7 for Sunday. Three-letter names work too, in any case: MON-FRI is the same as 1-5.

GitHub Actions, Kubernetes and Vercel document the day of week as 0-6, so write Sunday as 0 there, and Vercel doesn't accept names. AWS EventBridge and Quartz number the days 1-7 starting on Sunday, so weekdays are 2-6 or MON-FRI, and the other day field has to be ?.

Run a cron job on a specific date

A date goes in the third and fourth fields: the day of the month (1-31), then the month (1-12, or JAN to DEC). So 0 9 25 12 * runs at 09:00 on 25 December. Leave the day of the week as *.

Cron has no year field, so a date repeats every year. For a job that runs once, use at instead: echo /usr/local/bin/send-report | at 09:00 2026-12-25. A date that never comes, such as 0 0 31 2 *, is accepted but never runs, and 0 0 31 * * skips every month with 30 days or fewer.

Filling in both day fields doesn't narrow the date: cron runs when either one matches, so 0 9 13 * 5 runs on every 13th and on every Friday. For Friday the 13th, or for the last day of the month, which no field can express, schedule the possible days and let date decide in the command. Its % signs need a backslash, as the next section explains.

# Friday the 13th: run on every 13th, then test the weekday
0 9 13 * * [ "$(date +\%u)" = 5 ] && /usr/local/bin/friday-13th

# Last day of the month: run on the 28th-31st, then test tomorrow
0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = 01 ] && /usr/local/bin/month-end

date -d tomorrow is GNU date, as on Linux. In AWS EventBridge and Quartz, L in the day-of-month field means the last day, and 6#2 in the day of week means its second Friday.

Dates in a cron command: escape %

Cron treats % in the command part of a crontab line as a newline, and sends everything after the first one to the command as input. So date +%F, which works in a terminal, breaks in crontab: write each % as \%. Cron removes the backslash before it runs the command. The five schedule fields never contain %, so this only affects the command.

# Back up /var/www to a file named by date, such as site-2026-10-13.tgz
0 2 * * * tar -czf /backups/site-$(date +\%F).tgz /var/www

The date comes from the time zone cron runs in, usually the server's. To check a line before it runs, see how to edit crontab.