Cron runs on the server's wall clock — and that clock jumps twice a year. Most teams find out the hard way: a job that always ran at 02:30 silently disappears for one day, or a nightly task suddenly fires twice.
What actually happens:
- Spring-forward: 02:00 jumps to 03:00. A schedule set for 02:30 simply doesn't exist that day. The job never runs.
- Fall-back: 02:00 happens twice. A job at 02:30 can fire twice — which for billing, emails or data syncs can be a real bug.
Why it's so hard to spot: the crontab looks fine. The time zone is right. Nothing changed in your code. The clock just skipped or doubled an hour.
How to make schedules DST-proof:
- Run cron on UTC. UTC has no transitions, so
0 3 * * *always exists and always runs once. Map the wall-clock time yourself. - Or set
CRON_TZ=Zone/Namein the crontab so the whole file follows one named zone consistently. - Whatever you do, never compute "9am" by adding a fixed offset to UTC in shell — DST offsets change, fixed offsets don't.
I maintain a free cron builder that translates expressions into plain English and previews the next runs in your timezone, so these off-by-one DST surprises are visible before you deploy: https://cron-generator-kappa.vercel.app
Full guide with examples: https://cron-generator-kappa.vercel.app/guides/cron-timezone-dst
