The 5-field format

Every cron expression has exactly 5 fields, separated by spaces, always in the same order:

┌───────── minute (0-59)
│ ┌─────── hour (0-23)
│ │ ┌───── day of month (1-31)
│ │ │ ┌─── month (1-12)
│ │ │ │ ┌─ day of week (0-6, Sunday = 0)
│ │ │ │ │
* * * * *

Read it left to right: minute, hour, day, month, weekday. That's the one thing to burn into memory. Everything else follows from understanding what each field accepts.

Field operators

Each field accepts more than just single numbers. Here are the four operators you'll see:

You can combine operators in a single field. 1-5 in the weekday field means Monday through Friday. 0,30 in the minute field means twice per hour at :00 and :30.

Reading examples

Let's decode a few real-world expressions:

0 * * * *        → At minute 0 of every hour (hourly, on the hour)
30 2 * * *       → At 2:30 AM every day
0 9 * * 1-5      → At 9:00 AM, Monday through Friday
*/10 * * * *     → Every 10 minutes
0 0 1 * *        → At midnight on the 1st of every month
0 6 * * 0        → At 6:00 AM every Sunday
15 14 1 * *      → At 2:15 PM on the 1st of every month

The trick to reading cron: start from the right. The rightmost non-* field tells you the biggest cycle. Then work left for the exact timing.

Common patterns you'll encounter

These are the cron expressions you'll see most often in codebases. Bookmark this table — it covers 90% of real-world use cases.

Where cron is used in practice

You'll run into cron syntax in these contexts:

GitHub Actions

The schedule trigger uses cron directly:

on:
  schedule:
    - cron: '0 2 * * *'  # Every day at 2 AM UTC

Cloudflare Workers (Cron Triggers)

[triggers]
crons = ["*/5 * * * *"]  # Every 5 minutes

Linux crontab

The original. Edit with crontab -e:

# Backup database every night at 3 AM
0 3 * * * /usr/local/bin/backup.sh

# Clean temp files every Sunday at midnight
0 0 * * 0 /usr/local/bin/cleanup.sh

Node.js (node-cron)

import cron from 'node-cron';

// Send weekly report every Monday at 9 AM
cron.schedule('0 9 * * 1', () => {
  sendWeeklyReport();
});

Debugging cron schedules

When a scheduled job doesn't fire when expected, check these three things:

1. Timezone

Most cron systems run in UTC, not your local time. If your backup runs at "the wrong hour", it's probably correct in UTC.

# You want 9 AM Paris time (UTC+2 in summer)
# In UTC, that's 7 AM
0 7 * * *

2. Field order mistakes

The number one cron bug: swapping minute and hour. Read your expression back out loud.

# WRONG: "At hour 30, minute 9" — hour 30 doesn't exist
9 30 * * *

# RIGHT: "At minute 30, hour 9" — 9:30 AM
30 9 * * *

3. Day-of-month vs day-of-week conflicts

If you set both day-of-month AND day-of-week, most implementations run the job when either matches (OR logic), not when both match (AND logic). This is a classic source of "why does my job run on unexpected days?"

# Intended: "1st of the month, only if it's a Monday"
# Actual: "every 1st of the month AND every Monday"
0 0 1 * 1

# To get "1st Monday of the month", you need scripting logic,
# cron alone can't express this

Quick reference