Why do cron jobs break around daylight saving time?

When schedulers run in local time, DST transitions can create skipped or duplicated local clock times.

What is the safest default for cron schedules?

Use UTC for infrastructure jobs, then convert run times for display. If business rules require local wall-clock time, explicitly set timezone and test DST edge dates.

Cron and daylight saving time: ship schedules that do not surprise you

DST is where “works on my machine” cron setups go to die. Use this guide when timing matters for UK/Europe workflows and global systems.

What can go wrong

A local-time run disappears when clocks jump forward (spring).
A run can execute twice when clocks move back (autumn).
“9:00 UK” drifts if you hard-code UTC and forget BST/GMT changes.

Pick one scheduling intent (do not mix)

Fixed UTC intent: expression stays constant in UTC year-round. Best for pipelines and infrastructure jobs.
Fixed local wall-clock intent: always run at local time (for example 09:00 Europe/London), including DST shifts.

DST-safe pre-deploy checklist

Write down timezone intent (UTC or specific IANA zone like Europe/London).
Preview next runs in scheduler timezone and in local business timezone.
Check at least one known DST transition week.
Record expected timestamps in issue notes/on-call docs.
After deploy, verify scheduler-reported next run matches expectation.

Validate in Cron tool

Continue with related guides

Browse the full guides hub or open the Cron scheduler tool.