TechCompare LogoTechCompare

Cron timezone issues: why your job runs at the wrong time and how to fix it

Always set CRON_TZ in your crontab if you care about local time. Prefer UTC for server jobs and document that decision. For DST safety, check the behavior of your cron implementation and make the job idempotent. systemd separates wall-clock OnCalendar= timers from monotonic On*Sec= timers, so choose the one that matches whether the schedule is tied to a civil time or an elapsed interval.

Cron evaluates schedules against the system's local timezone, not UTC. This causes two classes of bugs: the server is set to UTC but you wrote the schedule in your local time, or the server is in a DST-observing timezone and your job skips or duplicates when the clocks change. Both are frustrating and both are preventable.

By TechCompare · Updated

Schedule pattern
Cron timezone pitfalls
timezone
Category
Pitfalls
Common cron mistakes and fixes

How this is calculated

On a UTC server, a 0 2 * * * job runs at 2 AM UTC. If you're in US Eastern time and thought '2 AM my time,' the job actually fires at 10 PM Eastern (or 9 PM depending on DST). The fix is to either set CRON_TZ=America/New_York in your crontab or adjust the hours: 0 7 * * * for 2 AM Eastern in standard time, 0 6 * * * during DST. DST behavior depends on the cron implementation. In Cronie, a fixed-time job in the skipped spring-forward interval runs immediately, and a duplicated fall-back time is not run twice when the clock change is under three hours. Other cron daemons may differ, so test the daemon and make the job idempotent.

Verdict

Two failure modes hide in timezone handling, and CRON_TZ is the clean fix for the server-versus-user mismatch. On a UTC box, 0 2 * * * fires at 2 AM UTC, not your local 2 AM, so shift to 0 7 for Eastern standard or 0 6 during DST. Do not treat skipped or repeated DST times as universal cron behavior. Cronie documents its own spring-forward and fall-back rules, while systemd offers separate wall-clock and monotonic timer types.

More Cron scenarios

Frequently asked questions

Does cron use UTC or local time?
Local system time, by default. Cron evaluates your schedule against whatever timezone the server is set to, which on cloud VMs and containers is usually UTC. A job you wrote thinking about your own timezone will fire hours off if the server disagrees. Check with timedatectl or date before assuming.
How do I make a cron job run in a specific timezone?
Set CRON_TZ at the top of the crontab: CRON_TZ=America/New_York followed by your schedules makes them evaluate against Eastern time regardless of the server's configured zone. Not every cron daemon supports CRON_TZ, so the portable fallback is running the server in UTC and converting your hour fields by hand.
What happens to cron jobs during daylight saving time changes?
It depends on the cron daemon. Cronie documents special handling for fixed-time jobs in the skipped spring-forward hour and for duplicate fall-back times, while other implementations can differ. Check the daemon's documentation, use an explicit timezone, and make the job idempotent or add a run guard when duplicate execution would be harmful.