← Blog  ·  October 2026

Cron Expression Cheat Sheet: Every Field, Character, and Common Schedule

A complete quick-reference for cron syntax — bookmark this one.

Cron expressions pack a lot of power into five (or six) fields separated by spaces. The syntax is compact and efficient, but nobody memorizes all of it. This cheat sheet is the reference you reach for when you need to confirm a character, build a schedule, or quickly understand what an expression does.

The five fields

A standard Unix/Linux cron expression has five fields:

┌─────────────── minute       (0–59)
│ ┌───────────── hour         (0–23)
│ │ ┌─────────── day of month (1–31)
│ │ │ ┌───────── month        (1–12 or JAN–DEC)
│ │ │ │ ┌─────── day of week  (0–6 or SUN–SAT, 0=Sunday)
│ │ │ │ │
* * * * *

Tools like Quartz Scheduler, Spring @Scheduled, and some cloud schedulers add a sixth field for seconds at the beginning, making it: second minute hour day-of-month month day-of-week. AWS EventBridge (CloudWatch Events) and GitHub Actions use a slightly different convention — check the platform docs.

Field reference

Special characters

30 common cron schedules

Every N minutes / hours

Daily schedules

Weekly schedules

Monthly schedules

Yearly / other

Day-of-month + day-of-week: the OR trap

When you specify both a day-of-month value and a day-of-week value (neither is *), cron uses OR logic, not AND. The job runs if either condition is true.

# This runs on the 1st of every month AND on every Monday
# NOT "on the first Monday of every month"
0 9 1 * 1

To target "first Monday of the month," you need application logic or a Quartz-style scheduler that supports the # character (0 9 ? * MON#1).

Month and day-of-week names

Most cron implementations accept 3-letter abbreviations in addition to numbers:

Names are case-insensitive in most implementations: MON, Mon, and mon are all accepted.

Platform-specific syntax differences

Common mistakes

1. Wrong day-of-week numbering

Most systems use 0 = Sunday. Some use 0 = Monday. A few accept both 0 and 7 for Sunday. Verify against your platform if weekend/weekday schedules look off.

2. Timezone confusion

Cron on a server runs in the server's local timezone (typically UTC). 0 9 * * 1-5 means 9 AM UTC, which may be 5 AM ET or 2 AM PT. Set timezone explicitly if your platform supports it, or calculate the UTC equivalent of your intended local time.

# GitHub Actions — runs at 9 AM ET (UTC-4 during EST / UTC-5 during EST)
# To run at 9 AM ET during standard time (EST = UTC-5):
0 14 * * 1-5   # 14:00 UTC = 9:00 AM EST

3. Assuming "every N minutes" starts at 0

*/5 * * * * runs at :00, :05, :10, :15... because it means "every 5th minute of the hour." It does not start counting from when the job was first created.

4. End-of-month scheduling

There is no standard way to schedule "last day of month" in Linux crontab. Common workaround:

# Runs on 28th, 29th, 30th, and 31st — then filter in the script
0 0 28-31 * * /usr/local/bin/check-and-run-if-last-day.sh

5. Job overlap (missing lock)

If a job takes longer than its interval, multiple instances will run simultaneously. Use flock or a file-based lock to prevent overlap:

*/5 * * * * flock -n /tmp/myjob.lock /path/to/myjob.sh

Step syntax reference

The / character means "every N, starting from the left value":

Validate before you deploy

The fastest way to avoid a misconfigured schedule in production is to test the expression before you commit it. Paste the expression into the free cron parser to see the plain-English description and next 10 run times — it catches timezone issues, OR-logic surprises, and day-numbering mistakes immediately.

Related guides

• Cron Job Not Running? A Practical Debug Guide
• Why Your Cron Jobs Fail Silently (and How to Know)
• GitHub Actions Scheduled Workflow Not Running: Causes and Fixes
• Cron Expression Examples: A Practical Reference Guide