Cron and Daylight Saving Time (DST)
Cron follows the server's local time, so jobs scheduled during the daylight-saving switch window can be skipped (spring forward) or run twice (fall back). The reliable fixes are to run cron in UTC or to avoid scheduling anything between 1 and 3 AM local time.
What goes wrong
In spring the clock jumps from 02:00 to 03:00, so a job set for 0 2 * * * is skipped that day. In autumn 02:00 happens twice, so the same job may run twice.
Fix 1: schedule outside the window
Avoid 01:00–03:00 local. A job at 0 4 * * * is never touched by a DST transition.
Fix 2: run cron in UTC
UTC has no DST, so timings never shift. Set the server with sudo timedatectl set-timezone UTC, or on systemd systems give a unit its own Environment=TZ=UTC. Note that modern Vixie cron tries to "catch up" jobs scheduled in the skipped hour, but behaviour differs by distro — don't rely on it.
Fix 3: make the job idempotent
If a double-run would cause harm, add a lock (flock) or a "already ran today" check so running twice is safe.
FAQ
Why does my cron job run twice on the DST change day?
In autumn the local clock passes 02:00 twice, so a job scheduled in that hour fires twice. Schedule it outside 1-3 AM or run cron in UTC.
Why was my cron job skipped?
In spring the clock jumps from 02:00 to 03:00, so anything scheduled in the skipped hour never fires that day. Move it to after 3 AM or use UTC.
How do I make cron immune to daylight saving?
Run the server (or the job's TZ) in UTC, which has no DST, and avoid scheduling jobs between 1 and 3 AM local time.