What Is a Cron Expression? – Definition and How It Works

Learn how cron fields work, the day-of-week OR trap, and why timezone and overlap handling matter for schedules.

A cron expression is a compact string describing a recurring schedule. It is the standard notation for scheduled jobs across Unix cron, Kubernetes CronJobs, and most orchestrators.

1. The Fields

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

2. Examples

The odd-minute point is worth taking seriously: everyone schedules on the hour, so 0 3 * * * puts your job in a crowd. An offset like 17 3 * * * avoids contention on shared infrastructure and, when the job makes external requests, avoids arriving at exactly the same moment as everyone else's.

3. The Day-of-Month / Day-of-Week Trap

The one genuinely counter-intuitive rule. When both day-of-month and day-of-week are restricted, cron treats them as OR, not AND:

0 0 13 * 5     →  the 13th of any month, OR any Friday — not "Friday the 13th"

Almost nobody expects that, and it silently produces far more runs than intended. To get an AND, restrict one field and check the other inside the job.

4. Timezones Are Where Schedules Break

Classic cron runs in the system timezone, which produces two failure modes around daylight saving:

• Spring forward — a job scheduled in the skipped hour does not run at all.
• Autumn back — a job in the repeated hour may run twice.

For anything where a missed or doubled run matters — a daily collection, a billing job — the mitigations are: schedule in UTC, or schedule outside the transition window (early afternoon UTC is safe), and make the job idempotent so a double run is harmless.

Idempotency is the robust answer, because it makes the whole class of scheduling anomalies survivable.

5. Overlap Is the Other Big One

Cron starts a job on schedule regardless of whether the previous run finished. A collection job scheduled every 15 minutes that sometimes takes 20 will overlap itself, and overlapping collection runs produce duplicate work and contended state.

Solutions, in order of preference:

1. Orchestrator-level prevention — Kubernetes concurrencyPolicy: Forbid, or the equivalent.
2. A lock file or advisory lock taken at start, released at exit.
3. A deadline so a hung run is killed rather than occupying the slot forever.

Never rely on "it usually finishes in time".

6. Non-Standard Extensions

Implementations add syntax beyond the classic five fields, and it is not portable:

• A seconds field, giving six fields — common in Quartz, Spring, and some orchestrators.
• @daily, @hourly, @reboot shorthands.
• L for last day of month, W for nearest weekday, # for nth weekday.
• ? as a no-specific-value marker.

Check which dialect your scheduler uses. A six-field expression pasted into a five-field parser is a common and confusing error, because the fields silently shift meaning.

7. Practical Guidance for Collection Schedules

1. Use UTC.
2. Offset from the hour to avoid contention and simultaneous external requests.
3. Prevent overlap explicitly.
4. Set a deadline on every scheduled run.
5. Make the job idempotent, so a missed, doubled, or retried run is safe.
6. Log the intended and actual start time, so drift and skipped runs are visible.
7. Avoid the both-days trap unless OR is genuinely what you want.

8. Summary

A cron expression describes a recurring schedule in five fields — minute, hour, day of month, month, day of week — with ranges, lists, and step values.

The traps that matter are the OR behaviour when both day fields are restricted, daylight-saving transitions that skip or double runs, and overlapping executions when a job outlasts its interval — so schedule in UTC at an offset minute, forbid concurrency, set a deadline, and make the job idempotent.

Potential Related Glossary

• Web Crawling
• Concurrency vs Parallelism
• Data Wrangling
• Data Structure