The five fields
A standard cron expression is five space-separated fields, each describing when a job should run:
┌───────────── minute (0–59)
│ ┌───────────── hour (0–23)
│ │ ┌───────────── day of month (1–31)
│ │ │ ┌───────────── month (1–12)
│ │ │ │ ┌───────────── day of week (0–6, Sunday=0)
│ │ │ │ │
* * * * *
0 9 * * 1-5 reads as: minute 0, hour 9, any day of month, any month, Monday through Friday — i.e., "9:00 AM every weekday." Cron has run this way, largely unchanged, on Unix-like systems since the 1970s, which is exactly why it's still the lowest-common-denominator scheduling format understood by CI systems, cloud schedulers (AWS EventBridge, GCP Cloud Scheduler), and container orchestrators alike.
The special characters
| Symbol | Meaning | Example |
|---|---|---|
* |
Every value | * * * * * = every minute |
, |
List of values | 0 9,17 * * * = 9 AM and 5 PM |
- |
Range | 0 9 * * 1-5 = Mon–Fri |
/ |
Step/interval | */15 * * * * = every 15 minutes |
? |
"No specific value" (day-of-month or day-of-week only, some implementations) | 0 0 ? * MON |
Steps and ranges combine: 10-30/5 * * * * means "minutes 10, 15, 20, 25, 30" — starting at 10, stepping by 5, capped at 30.
The day-of-month / day-of-week trap
This is the single most common source of confusion. When both day-of-month and day-of-week are restricted (not *), most cron implementations treat them as OR, not AND: 0 0 15 * 1 runs at midnight on the 15th of the month or every Monday — not only on Mondays that happen to be the 15th. If you actually need "the 15th, but only if it's a Monday," you need application-level logic, not cron alone.
Named shortcuts
Most modern schedulers accept these aliases in place of a five-field expression:
@yearly/@annually→0 0 1 1 *@monthly→0 0 1 * *@weekly→0 0 * * 0@daily/@midnight→0 0 * * *@hourly→0 * * * *
Timezone gotchas
Cron itself has no built-in concept of timezone by default — a job scheduled 0 9 * * * runs at 9 AM in whatever timezone the scheduling system's clock is set to, which for servers is very often UTC, not the timezone the person writing the schedule was thinking in. Cloud schedulers (EventBridge, Cloud Scheduler) let you set a timezone explicitly per job — always check this setting rather than assuming local time, especially around Daylight Saving Time transitions, where a 2 AM schedule can run twice or not at all on the transition day.
Common mistakes
- Forgetting Sunday can be
0or7. Both are valid depending on implementation — always verify which convention your specific scheduler follows. - Assuming day-of-month AND day-of-week when both are set. As above, most implementations OR them, not AND.
- Off-by-one on hours after a timezone change. A schedule that "always ran at 9 AM" can silently shift an hour around DST boundaries if the underlying system uses local time instead of UTC.
- Overlapping schedules from
,and/combined incorrectly.0 */2,9-17 * * *doesn't mean what most people expect — combining ranges and steps in one field needs care, and splitting into two separate jobs is often clearer than a dense one-liner.
FAQ
What does * * * * * mean?
"Every minute, of every hour, of every day" — the job runs once per minute continuously.
How do I run a job every 15 minutes?*/15 * * * * — the /15 step means minute 0, 15, 30, 45.
Does cron account for leap years and month lengths automatically?
Yes — if you schedule day 31 in a month with fewer days, that run is simply skipped for that month; cron doesn't error, it just never matches.
Can I combine day-of-month and day-of-week to mean AND instead of OR?
Not with standard cron syntax — you'd need to add a conditional check inside the job itself (e.g., skip execution unless today matches both conditions).
Paste any expression into the Cron Expression Descriptor to get a plain-English translation and the next run times, entirely client-side.