The five fields
A standard cron expression has five space-separated fields, in this order:
minute hour day-of-month month day-of-week
- Minute — 0 to 59
- Hour — 0 to 23
- Day of month — 1 to 31
- Month — 1 to 12
- Day of week — 0 to 6, where 0 is Sunday (many implementations also accept 7 for Sunday)
So 0 3 * * 1 means minute 0, hour 3, any day of month, any month, Monday — 3:00am every Monday.
The operators
*— every value in the field,— a list, as in1,15,30-— a range, as in9-17/— a step, as in*/15for every 15 units
Steps combine with ranges: 0-30/10 means minutes 0, 10, 20, and 30.
A common misreading is that */20 in the minute field means “every 20 minutes” in a rolling sense. It does not — it means minutes 0, 20, and 40 of each hour, anchored to the top of the hour rather than to when the job was last run.
The day-of-month and day-of-week trap
This is the single most confusing behaviour in cron, and it catches experienced engineers.
When both the day-of-month and day-of-week fields are restricted (neither is *), most cron implementations treat them as OR, not AND.
So 0 0 13 * 5 does not mean “midnight on Friday the 13th”. It means “midnight on the 13th of any month, and also midnight every Friday” — which is a great deal more often than intended.
When only one of the two is restricted, the behaviour is intuitive. The OR applies only when both are set. There is no portable way to express AND in standard cron; it usually has to be handled with a condition inside the job itself.
Time zones and daylight saving
Cron runs in the system's local time zone unless configured otherwise, which produces two predictable failures twice a year.
On spring forward, an hour is skipped. A job scheduled at 2:30am on that day simply does not run. On autumn back, an hour repeats, so a 1:30am job may run twice.
Some implementations attempt to compensate, and behaviour differs between them — which makes this hard to reason about portably.
The robust approach is to run cron in UTC and handle any local-time presentation inside the application. Where a job must run at a specific local time, schedule it outside the 1am–3am window where transitions occur.
Jobs should also be idempotent where possible, so running twice is harmless. That removes an entire class of problem rather than working around it.
Special strings and extensions
Most implementations accept convenience shorthands: @yearly, @monthly, @weekly, @daily, @hourly, and @reboot.
Extended syntaxes add fields and operators. Quartz, used widely in the Java ecosystem, adds a seconds field at the front and an optional year at the end, plus L for last, W for nearest weekday, and # for “nth weekday of the month”. AWS EventBridge uses a six-field format with its own rules and requires ? in one of the day fields.
These are not interchangeable. An expression copied from one system frequently means something different or is rejected outright on another — always check which dialect your scheduler expects.
Frequently asked questions
What do the five fields in cron mean?
Minute, hour, day of month, month, and day of week, in that order. Day of week uses 0 for Sunday, with many implementations also accepting 7.
Why does my Friday the 13th cron job run every Friday?
When both day-of-month and day-of-week are restricted, most cron implementations treat them as OR rather than AND. So 0 0 13 * 5 runs on the 13th and also every Friday.
Does */20 mean every 20 minutes?
It means minutes 0, 20, and 40 of each hour, anchored to the top of the hour rather than to when the job last ran. The distinction matters at hour boundaries.
How should I handle daylight saving in cron?
Run cron in UTC and handle local time in the application. A job scheduled during the transition window may be skipped or run twice, and behaviour differs between implementations.