Skip to content
Development

Cron Expressions Explained: Fields, Examples, and Scheduling Traps

The expression selects calendar times; the scheduler and job determine what happens around them.

Cron Expressions Explained: Fields, Examples, and Scheduling Traps

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.

ExpressionMeaning in this five-field dialect
0 * * * *At minute zero of each hour
30 6 * * *Daily at 6:30 AM
0 9 * * 1-5At 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.
Top