Cron Expression Explainer: Crontab to Plain English

Anatomy of a cron expression

Standard cron uses five space-separated fields: minute (0-59), hour (0-23), day of month (1-31), month (1-12), and day of week (0-7, where both 0 and 7 mean Sunday). A job runs whenever the current time matches all the time fields. '30 2 * * 0' reads as minute 30, hour 2, any day of the month, any month, Sunday, so 2:30 AM every Sunday.

Months accept names (JAN-DEC) and weekdays accept names (SUN-SAT), case-insensitive. Hours use a 24-hour clock: 13 is 1 PM and 0 is midnight. There is no seconds field in standard cron; the smallest interval is one minute.

The special characters

An asterisk means every value. A comma makes a list: '0,30' in the minute field runs at :00 and :30. A hyphen makes an inclusive range: '9-17' in the hour field covers 9 AM through 5 PM, and the explainer shows it as between 9:00 AM and 5:59 PM, since the minute field keeps firing through the last hour.

A slash adds a step. '*/15' means every 15 starting from the lowest value, so minutes 0, 15, 30, and 45. A step can apply to a range: '8-18/2' in the hour field is 8, 10, 12, 14, 16, and 18. Some implementations also accept a start with a step, '5/10', meaning 5, 15, 25, and so on to the end of the range; the explainer reads it that way, but write '5-59/10' if you need portability. Note that '*/7' in the day-of-month field restarts every month (1, 8, 15, 22, 29), so it is not a true every-seven-days schedule.

Worked examples

'*/15 9-17 * * 1-5': every 15 minutes from 9:00 AM to 5:45 PM, Monday through Friday. A common schedule for syncing data during business hours. '0 0 1 * *': midnight on the first of every month, typical for monthly reports and billing. '0 */6 * * *': at minute 0 every six hours, so midnight, 6 AM, noon, and 6 PM.

'0 9 13 * 5' is the classic trap. It does not mean Friday the 13th. When both day of month and day of week are restricted, standard Vixie cron, used on most Linux systems, runs the job when either matches, so this fires on the 13th of every month and on every Friday. The explainer spells this out, and the next-runs list makes it obvious.

Macros and variants

Most cron implementations accept shortcuts: @yearly or @annually (0 0 1 1 *), @monthly (0 0 1 * *), @weekly (0 0 * * 0), @daily or @midnight (0 0 * * *), and @hourly (0 * * * *). @reboot runs once when the cron daemon starts. The explainer expands each macro to its five-field form.

Not every scheduler is standard cron. Quartz (Java) and Spring add a seconds field at the front and use ? for 'no specific value'. AWS EventBridge adds a year field and requires ? in either day field. GitHub Actions schedules use standard five-field syntax but always run in UTC and can be delayed during busy periods. If you paste six fields, the tool tells you it looks like a Quartz-style expression.

Time zones and daylight saving

Cron runs in the time zone of the machine it runs on. Cloud servers and containers usually default to UTC, so '0 9 * * *' fires at 9 AM UTC, which is 4 or 5 AM in New York depending on daylight saving. The next-run list here uses your browser's local time; convert with the time zone converter if your server is elsewhere.

Daylight saving creates edge cases on servers set to a local zone. In the US, clocks jump from 2:00 to 3:00 AM in March, so a job scheduled at 2:30 AM may be skipped that day, and in November the 1:00 hour repeats, so a 1:30 AM job may run twice depending on the implementation. Scheduling critical jobs outside 1 to 3 AM, or running servers in UTC, avoids both problems.

Debugging a job that won't run

If the expression is right but nothing happens, check the usual suspects: the cron daemon's PATH is minimal, so use absolute paths to commands; the script needs execute permission; output goes nowhere unless you redirect it (append >> /var/log/myjob.log 2>&1); and % characters must be escaped as \% in crontab lines. The explainer confirms your schedule; the log confirms your command.