Cron Expressions Explained: Fields, Examples, and Scheduling Traps
The expression selects calendar times; the scheduler and job determine what happens around them.
Key takeaways
- Traditional five-field cron reads minute, hour, day of month, month, and day of week.
- Steps select values within a field rather than measuring elapsed time from the last run.
- Day-field matching, extra fields, time zones, and daylight saving behavior depend on the scheduler.
- A schedule does not by itself prevent overlap, recover missed work, or prove successful completion.
A cron expression describes calendar times at which a scheduler should start work. In traditional five-field Unix cron, 0 2 * * * means 2:00 AM every day in the scheduler’s applicable time zone.
Imagine a business importing supplier inventory every fifteen minutes. The expression is short, but the full requirement includes what happens when an import takes twenty minutes, the machine is unavailable, or local clocks change.
Understanding cron means reading both the fields and the scheduler’s execution rules.
Read the Five Fields in Order
minute hour day-of-month month day-of-week
A user crontab entry adds a command after the expression:
*/15 * * * * /usr/local/bin/import-inventory
System crontab formats can include an additional user field. Do not confuse that field with part of the schedule.
The crontab manual documents a common Linux implementation, including ranges, lists, steps, and day matching.
| Expression | Meaning in this five-field dialect |
|---|---|
0 * * * * | At minute zero of each hour |
30 6 * * * | Daily at 6:30 AM |
0 9 * * 1-5 | At 9 AM Monday through Friday |
0 9,12,17 * * * | Daily at 9 AM, noon, and 5 PM |
0 12 1 * * | Noon on the first of each month |
An asterisk selects every valid value in its field. Therefore * 2 * * * runs every minute during the 2 AM hour, not just once at 2 AM.
Steps Reset Within Their Field
The inventory expression */15 * * * * selects minutes 0, 15, 30, and 45.
It does not mean fifteen minutes after the previous execution finishes. An import starting at 10:00 can still be running when the 10:15 occurrence arrives.
Likewise, */40 * * * * selects minutes 0 and 40 of every hour. The gaps alternate between forty and twenty minutes.
If the requirement is a fixed delay after completion, use a scheduling mechanism that explicitly provides that behavior rather than approximating it with calendar fields.
Two Day Restrictions Can Mean Either
In common traditional cron implementations, when both day of month and day of week are restricted, a match in either field can select the date.
For example:
0 9 1 * 1
This commonly means 9 AM on the first of each month and on Mondays. It does not mean only when the first is a Monday.
For requirements such as the first working day of a month, a calendar-aware scheduler or an explicit date check in the job may be clearer. Holidays introduce rules that weekday numbers alone cannot describe.
The Dialect Is Part of the Expression
Some schedulers include seconds, a year field, or special characters that traditional five-field cron does not support.
An expression copied from another product may be rejected or interpreted differently. Confirm the field count and syntax against the system that will execute it.
Kubernetes CronJobs also define behavior around concurrency, missed scheduling, and time-zone configuration beyond the cron expression itself.
A generic expression explainer cannot establish all of those product-specific properties.
State the Time Zone Explicitly
A schedule such as 9 AM has no business meaning until its zone is known.
For a supplier operating in Auckland, UTC and Pacific/Auckland represent different requirements. A UTC schedule avoids local clock discontinuities, but its local business time can shift seasonally.
Daylight saving can make local times nonexistent or repeated. How those occurrences are handled depends on the scheduler. Review upcoming runs around transitions rather than assuming every local day has twenty-four distinct hours.
Also distinguish the scheduler’s zone from the zone used in logs.
Prevent Overlap Deliberately
If the inventory import takes twenty minutes, decide what should happen to the next fifteen-minute occurrence.
The business might skip it, queue it, or permit parallel work on separate data partitions. Those choices have different effects on freshness and load.
A lock can prevent overlap on one machine, but may not coordinate multiple machines. A scheduler’s concurrency policy may apply only to jobs from that particular schedule.
Make repeated work safe where practical. For example, identify an import batch so retrying it does not apply the same adjustment twice.
Monitor Completed Work
A process starting does not prove that inventory was updated.
Record the intended run time, actual start, outcome, duration, and the last supplier data successfully imported. Alert on stale data as well as process errors.
Keep the command’s runtime environment explicit, including executable paths, configuration, permissions, and working directory. A command working in an interactive terminal may rely on settings absent from the scheduler.
For the inventory job, review the calendar schedule alongside workflow recovery and system design. The complete design should explain how late, missing, duplicate, and failed runs affect the business result.
Knowing when a job should start is different from knowing that its work was completed.
More Articles Like This
What Is a .dockerignore File? Build Context, Patterns, and Common Mistakes
