How to Understand Cron Expressions (with 18 Practical Examples)

The five fields of a cron expression

Cron is the classic Unix job scheduler, and its schedule syntax is now used far beyond Unix — in Kubernetes CronJobs, CI systems, cloud schedulers and application libraries. A standard cron expression has five fields separated by spaces. A job runs at every minute where all the fields match the current time (with one important exception for the two day fields, covered below).

┌───────────── 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

Special characters and shortcuts

Steps start at the beginning of the range, not at the current time: */7 in the minute field fires at minutes 0, 7, 14 … 56 and then again at 0, so the gap across the hour is only 4 minutes. If you need a true "every N minutes" interval that does not divide 60, use a scheduler with interval support instead.

Vixie cron and its descendants (including cronie, common on Linux) also accept shortcut strings in place of the five fields: @yearly (or @annually), @monthly, @weekly, @daily (or @midnight), @hourly and @reboot, which runs once when the cron daemon starts. Support for these varies outside classic cron, so check your platform.

15+ practical cron examples

Each of these uses the standard five-field syntax. Paste any of them into the Cron Generator to see the next run times.

Standard cron has no syntax for "the last day of the month". A common workaround runs the job on days 28–31 and lets the command check whether tomorrow is the 1st. Note that % must be escaped as \% inside a crontab line, because cron treats an unescaped % as a newline:

0 23 28-31 * * [ "$(date -d tomorrow +\%d)" = "01" ] && /usr/local/bin/month-end-report

The day-of-month / day-of-week OR rule

This is the most common cron surprise. In Vixie cron and most compatible implementations, if both the day-of-month and day-of-week fields are restricted (neither is *), the job runs when either matches — not when both do.

• 0 0 1 * 1 runs on the 1st of every month and on every Monday — not only on Mondays that fall on the 1st.
• 0 0 13 * 5 runs on every 13th and every Friday, not just on Friday the 13th.
• 0 0 * * 1 runs only on Mondays, because the day-of-month field is * and therefore does not take part.

Timezones and daylight saving time

Classic cron interprets schedules in the system's local timezone. That makes 30 2 * * * ambiguous on days when daylight saving time changes: in many zones 02:30 does not exist on the spring-forward day and occurs twice on the fall-back day. Implementations handle this differently — some run the job once, some skip it, some run it twice — so do not rely on any particular behaviour.

• Run servers in UTC where possible. UTC has no daylight saving changes, so every schedule is unambiguous.
• Avoid 01:00–03:00 local time for important jobs if you must use a zone with DST.
• Check per-job timezone support. cronie supports a CRON_TZ variable in the crontab; Kubernetes CronJobs accept spec.timeZone; GitHub Actions scheduled workflows always use UTC.
• Convert when reading logs. The Timestamp Converter helps translate between UTC and local times when checking when a job really ran.

Cron dialects on different platforms

Before copying an expression between systems, count the fields. A six-field expression pasted into a five-field system will either be rejected or, worse, be read with every field shifted by one position.

Building and testing a schedule step by step

1. Describe the schedule in words first, including the timezone: "every weekday at 07:30 UTC".
2. Build the expression in the Cron Generator or write it by hand: 30 7 * * 1-5.
3. Check the next few run times the generator lists, especially around month ends and weekends.
4. Install it with crontab -e, and confirm with crontab -l.
5. Redirect output to a log so failures are visible, as shown below, and check the log after the first scheduled run.

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

Jobs that work in your shell but fail under cron almost always depend on environment variables, a relative path or the current directory. For more automation helpers, browse the DevOps tools category.