Skip to main content

Why Does My Cron Job Run at the Wrong Time?

Cron usually runs according to the scheduler host’s configured time zone and its own crontab rules, not your browser or workstation. Wrong-time reports often come from a zone mismatch, daylight-saving transition, misunderstood fields, or duplicate schedulers.

Connect the timing symptom to its clock

SymptomLikely checkEvidence
Consistent offset of hoursScheduler and log time zonesUTC timestamp plus offset
Twice or not at DST changeLocal-time transition policyZone and transition date
Runs twice every timeDuplicate crontabs/replicasHost and execution ID
Starts on time but finishes lateOverlap or downstream delayStart/end timestamps and lock state

Establish which clock and scheduler are authoritative

First identify the machine, container, or managed service that evaluates the expression. Record its current time, time zone, scheduler implementation, and the exact installed crontab - Not merely the deployment source file. System crontabs may include a user field that per-user crontabs do not, and hosted schedulers may use UTC or a documented custom syntax.

A log timestamp can mislead when the scheduler logs in UTC, the application logs in local time, and an observability service displays the viewer’s zone. Log an unambiguous RFC 3339 time with offset, the job identifier, host identity, and an execution ID at job start. That evidence distinguishes a scheduling error from delayed work, queueing, or slow startup.

Local civil time has gaps and repetitions

Daylight-saving changes mean a local wall-clock time can fail to occur or occur twice. Cron implementations differ in how they treat those transitions. For a job that represents elapsed intervals or must run exactly once, UTC plus explicit business logic may be safer. For a task tied to local civil time, document the intended behavior during transitions and test the scheduler you actually operate.

Trace the schedule from expression to execution

  • Capture the installed schedule, scheduler implementation, host identity, current zone, and UTC time.

  • Use absolute command paths and log the environment needed by the job.

  • Add overlap protection or idempotency when a prior run may still be active.

  • Test weekday, month boundary, leap day, and daylight-saving behavior that matters to the business.

Read all five fields in order

15 2 * * 1-5 /opt/jobs/report
│  │ │ │ └─ Monday through Friday
│  │ │ └── month
│  │ └──── day of month
│  └────── hour 02
└───────── minute 15

This means 02:15 in the scheduler’s applicable time zone on weekdays. Whether it runs during a skipped or repeated 02:15 depends on that scheduler and zone transition.

Cron changes that mask the real timing problem

  • Cron has a minimal environment; a job that “did not run” may have started and immediately failed because PATH or credentials differed.
  • A container’s zone and the host’s zone can differ, while a managed scheduler may ignore both and use UTC.
  • Editing one user’s crontab does not remove the same job from system cron, another account, an orchestrator, or another replica.

Cron timezone and scheduling questions

Does cron use UTC?

It depends on the implementation and environment. Many systems use the host’s local zone, while hosted schedulers often document UTC; verify rather than assume.

Will cron catch up after the server was off?

Traditional cron normally does not replay every missed run. Other schedulers and tools such as anacron have different semantics.

Continue the investigation

Check Unix timestamp units when the evidence crosses into that problem. Use the Cron Expression Builder with a safe, non-sensitive sample to confirm the result.

Technical references used for this diagnosis