Cron Expression Guide: Syntax, Fields & Platform Differences

Cron is a time-based job scheduler built into Unix-like operating systems. A cron expression is a compact string that defines when a job should run — once you understand the five fields and the handful of special characters, you can express almost any schedule imaginable, from "every minute" to "at 8:45 AM on the first Monday of every quarter." This is the reference page for the syntax itself; if you have a specific expression already and just want it explained, the free Cron Expression Explainer will do that instantly.

The Five Fields

Every standard cron expression has exactly five fields separated by spaces:

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

Special Characters

• * — matches every possible value for that field.
• , — list separator. 1,3,5 means the 1st, 3rd, and 5th.
• - — range. 1-5 means 1 through 5.
• / — step. */10 means every 10 units, starting from 0.

10 Practical Examples

• * * * * * — every minute
• 0 * * * * — every hour on the hour
• 0 0 * * * — every day at midnight
• 0 9 * * 1-5 — weekdays at 9:00 AM
• */15 * * * * — every 15 minutes
• 0 0 1 * * — first day of every month at midnight
• 30 18 * * 5 — every Friday at 6:30 PM
• 0 8,12,18 * * * — at 8 AM, noon, and 6 PM daily
• 0 0 * * 0 — every Sunday at midnight
• 0 2 * * 1 — every Monday at 2:00 AM (good for weekly backups)

Need "every 5 minutes" specifically, with more variations? See cron every 5 minutes: expression and examples.

Real-World Application Patterns

Beyond the syntax, here's what these expressions actually get used for in production:

• Database backups — 0 2 * * *, nightly during low-traffic hours, before the day's data volume makes the backup window too long.
• Log rotation and cleanup — 0 0 * * 0, weekly, deleting or archiving logs older than a retention window so disk usage doesn't grow unbounded.
• Cache warming — */15 * * * *, refreshing a computed cache slightly before it would otherwise expire, so users never hit a cold cache.
• Scheduled reports — 0 8 1 * *, generating and emailing a monthly summary on the 1st at 8 AM, timed to land before the workday starts.
• Health checks and monitoring pings — */5 * * * *, checking a service is still responding and alerting if a run is missed (see the monitoring guide linked below for how to detect a silent failure — a cron job that stops running without erroring).
• Token or session cleanup — 0 3 * * *, nightly removal of expired auth tokens or stale sessions from the database.

Common Mistakes to Avoid

• Confusing day-of-week numbering — Sunday is 0 on most systems, but 7 is also accepted on some.
• Forgetting that month and day-of-month are 1-indexed while hour and minute are 0-indexed.
• Using 0/5 instead of */5 — both work but */5 is clearer.
• Writing six fields for a standard crontab — the extra field (seconds or year) is only understood by specific schedulers like Quartz or node-cron, not plain Unix cron.
• Specifying both day-of-month and day-of-week and assuming it means "and" — on standard cron it means "or": the job runs if either field matches.

Platform Comparison

Cron syntax is mostly standard, but every platform that implements it has quirks:

For the Quartz/Java seconds-field trap specifically, see Cron vs Quartz in Java.

Troubleshooting: My Cron Job Isn't Running

The short version — check these in order:

1. Is the cron daemon actually running? (systemctl status cron on most Linux distros)
2. Does the crontab use an absolute path to the script, not a relative one?
3. Does the script depend on environment variables that exist in your login shell but not in cron's minimal environment?
4. Does the file running the job have execute permission?

For the full checklist with the exact commands to run for each check, see Cron Job Not Running? 5 Fixes That Actually Work.

Frequently Asked Questions