Cron Expression Syntax: A Complete Guide

A cron expression is a string of 5 (or 6) fields that defines a recurring schedule for running automated tasks. It is the standard format used in Unix cron jobs, CI/CD pipelines, cloud schedulers (AWS EventBridge, GitHub Actions), and most backend job frameworks.

What does each field in a cron expression mean?

┌─────────── 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)
│ │ │ │ │
* * * * *

Some systems add a 6th field for seconds (Quartz, Spring) at the beginning, or a 6th year field at the end.

What do the special characters (* , - / L W #) do?

What are common cron schedule examples?

Can I use month and day-of-week names instead of numbers?

How do cron implementations differ across platforms?

How do timezones affect cron schedules?

The schedule 0 9 * * * means "9 AM" — but in which timezone? The answer depends on where the cron daemon runs, not where you wrote the expression. A schedule that fires at 9 AM in your local editor can land at 1 AM in production if the host is set to UTC.

• System cron (Linux): reads the TZ environment variable, otherwise uses /etc/localtime. Inside Docker, the default is UTC unless the image setsTZ or mounts /etc/localtime.
• vixie/cronie: supports a CRON_TZ=Europe/Stockholm line at the top of a crontab to pin the schedule to a named zone.
• GitHub Actions: always UTC. 0 9 * * * fires at 09:00 UTC, which is 04:00 in New York during EST. There is no per-workflow timezone option.
• AWS EventBridge: historic Rules use UTC only. EventBridge Scheduler (released 2022) accepts a ScheduleExpressionTimezone parameter, including DST-aware zones like America/New_York.
• Daylight Saving Time: a job scheduled for 02:30 local can run twice on fall-back day or skip on spring-forward day. UTC sidesteps both.

For workflow-specific tips, see the GitHub Actions cheatsheet.

How do I debug a cron job that doesn't run?

Most failed cron jobs aren't broken cron expressions — they're environment, path, or permission problems. Walk through these checks in order:

1. Confirm the entry is installed: run crontab -l as the user that owns the job. System-wide entries live in /etc/crontab and /etc/cron.d/*.
2. Check cron logs: on Debian/Ubuntu look at /var/log/syslog filtered with grep CRON; on RHEL/CentOS check /var/log/cron; under systemd use journalctl -u cron or journalctl -u crond.
3. Cron has a minimal PATH: usually only /usr/bin:/bin. Use absolute paths in commands or set PATH=... at the top of the crontab.
4. Capture stderr: append >> /var/log/myjob.log 2>&1 to the command, or set MAILTO=ops@example.com at the top of the crontab to receive failures by email.
5. End the line with a newline: entries without a trailing newline are silently ignored on some implementations.
6. Validate the expression: paste it into the Cron Expression Parser to see the next 5 fire times. If they don't match what you expected, the bug is in the expression.
7. Container caveats: Docker images often ship without a cron daemon, run with PID 1 not forking, and default to UTC. Use a sidecar scheduler or your platform's native scheduler (EventBridge, Cloud Scheduler, Kubernetes CronJob) instead of stuffing cron inside an app container.

References

• crontab(5) — Linux man page — the canonical 5-field syntax, environment variables, and operator semantics.
• AWS EventBridge cron expressions — 6-field format with the trailing year field, UTC default, and EventBridge-specific quirks like the ? wildcard.
• GitHub Actions schedule trigger — POSIX 5-field cron, UTC only, with notes on shortest interval (5 minutes) and runner availability.
• Quartz CronTrigger tutorial — the 6/7-field Java/Spring dialect with seconds, year, and the L W # operators.
• crontab.guru — interactive editor that explains any 5-field expression in plain English.