The hour that happens twice
At 01:00 UTC on Sunday 25 October 2026, most of Europe turns its clocks back. In Amsterdam 03:00 CEST becomes 02:00 CET, and the hour from 02:00 to 02:59 plays twice. A job set for 02:30 local now has two candidates: 00:30 UTC and 01:30 UTC. The US follows on 1 November, repeating 01:00 to 01:59.
Which one fires, and how often, depends on the scheduler.
It is also the first autumn for GitHub Actions schedules with a time zone. The timezone: field shipped in the late March 2026 Actions changelog, and the docs only describe spring.
What each scheduler does with the repeated hour
cronie: two man pages, two answers
cronie, the cron on RHEL, Fedora and Arch, contradicts itself. crontab(5) says times that occur more than once "will cause matching jobs to be run twice". cron(8) says that after a backward adjustment "running the same job twice is avoided" for fixed-time jobs.
cron.c settles it, mostly. A backward jump under three hours runs wildcard jobs only, but the jump is measured in the daemon's own zone. Put the host on UTC and set CRON_TZ=Europe/Amsterdam in the crontab, and the daemon sees no jump at all. It checks every minute in the job's zone, meets 02:30 twice, and crontab(5) is right.
Debian and Ubuntu cron
Debian runs a patched Vixie cron with the same three-hour rule. Its cron(8) says jobs in the repeated time "will not be re-run". That only covers jobs at a particular time. Anything with * in the hour or minute field, or @hourly, follows the new clock, so a */15 job fires in both passes of the hour. Usually that's what you want.
systemd timers
systemd.time(7) takes an IANA zone at the end of OnCalendar= and says nothing about DST. So we asked systemd-analyze on Debian 12, systemd 252:
systemd-analyze calendar --iterations=3 \
--base-time='2026-10-24 12:00 UTC' \
'*-*-* 02:30:00 Europe/Amsterdam'
Next elapse: Sun 2026-10-25 00:30:00 UTC
Iter. #2: Mon 2026-10-26 01:30:00 UTC
Iter. #3: Tue 2026-10-27 01:30:00 UTC
One run, at the first 02:30. In spring the 29 March run was skipped outright. That is one version. Run the command on yours.
Kubernetes CronJobs
.spec.timeZone has been GA since Kubernetes 1.27, and the CronJob docs never mention daylight saving. The controller uses robfig/cron/v3, whose docs warn that "jobs scheduled during daylight-savings leap-ahead transitions will not be run!" About falling back they say nothing. Maintainers of the netresearch/go-cron fork opened an issue in November 2025 because nobody could say whether a repeated-hour job runs once or twice. Assume twice until staging proves otherwise.
GitHub Actions
GitHub documents spring only: with a DST-observing timezone, a schedule in the skipped hour will "advance to the next valid time", so 02:30 becomes 03:00. The repeated hour isn't mentioned. A 01:30 America/New_York workflow on 1 November is anyone's guess.
AWS EventBridge Scheduler
EventBridge Scheduler is the only one here that writes both cases down. A spring invocation on a non-existent time is skipped. In autumn "your schedule runs only once and does not repeat its invocation", at the first occurrence. rate(1 days) means 24 hours flat.
Find your exposed jobs before Sunday
Look at anything pinned between 01:00 and 02:59 local time. Start with host crontabs:
awk '!/^[[:space:]]*#/ && NF >= 6 && $2 ~ /(^|,)0?[12](,|$)/ { print FILENAME": "$0 }' \
/etc/crontab /etc/cron.d/* /var/spool/cron/crontabs/* /var/spool/cron/* 2>/dev/null
grep -rn 'CRON_TZ' /etc/crontab /etc/cron.d /var/spool/cron 2>/dev/null
The CRON_TZ check matters most on UTC hosts, where cronie's guard doesn't reach. For timers, run each zoned OnCalendar= through the systemd-analyze check above. For Kubernetes and GitHub:
kubectl get cronjobs -A \
-o custom-columns=NS:.metadata.namespace,NAME:.metadata.name,SCHEDULE:.spec.schedule,TZ:.spec.timeZone
grep -rn -A1 'cron:' .github/workflows/ | grep -B1 'timezone:'
Make a second run harmless
Move the job or schedule it in UTC
The cheapest fix is moving it. A nightly job at 04:00 local never meets the repeated hour in Europe or the US. If it doesn't need local business hours, schedule it in UTC.
Key the work on the local date
When the time is fixed for a reason, make the job refuse to do the same day twice. On one host a stamp file does it:
#!/bin/bash
set -euo pipefail
stamp="/var/lib/nightly-report/$(TZ=Europe/Amsterdam date +%F).done"
[ -e "$stamp" ] && exit 0
/usr/local/bin/build-nightly-report
touch "$stamp"
Across several hosts you need a shared store, like a unique row per day in the database the job already writes to.
Watch the run, not the clock
DST trips up monitoring too. A daily 02:30 Amsterdam job runs at 00:30 UTC on 25 October and 01:30 UTC the next day: 25 hours apart. A check-in monitor expecting 24 hours with a 30-minute grace pages someone for nothing. Use one that follows the cron expression in the job's zone. And a dead man's switch only alerts on missing runs. If a duplicate costs money, log a run ID with each check-in and count them on Monday.
Frequently asked questions about DST and the repeated hour
When do clocks go back in 2026? Most of Europe falls back on Sunday 25 October at 01:00 UTC, the United States on Sunday 1 November. Amsterdam repeats 02:00 to 02:59, New York repeats 01:00 to 01:59.
Will a cron job at 02:30 run twice when the clocks go back? On cronie and Debian cron with the host in a DST zone, a fixed-time job is not repeated, because cron(8) skips the repeated time for jobs at a particular hour. Cronie's own crontab(5) page still says such jobs run twice, and that is what to expect on a UTC host that sets CRON_TZ to a local zone.
How do systemd timers handle the repeated hour? The documentation does not say. Tested with systemd-analyze on systemd 252, a daily 02:30 Europe/Amsterdam timer fired once, at the first 02:30.
Do GitHub Actions scheduled workflows with a timezone run twice in autumn? GitHub only documents spring, where a schedule in the skipped hour moves to the next valid time. Nothing is written about the repeated hour, so test any workflow scheduled in that hour rather than assuming it runs once.
Why does my daily job monitor fire a false alarm after the clock change? A daily job pinned to local time runs 25 hours apart across the autumn change. A monitor expecting a fixed 24 hours with a short grace flags that as a missed run. Use one that follows the cron schedule in the job's zone.
Further reading
- Time Zone Changes Are Moving When Your Cron Jobs Run
- Monitoring systemd Timers: The Cron Successor Fails Just as Quietly
- Why Your GitHub Actions Scheduled Workflows Run Hours Late
Conclusion: Nobody should have to read a scheduler's source to know whether a backup runs twice on a Sunday in October, but for cronie and Kubernetes that is where the answer lives. Don't count on getting it right. Get the jobs out of the 01:00 to 02:59 window this week, and the ones that have to stay there should shrug off a second run.
Sources: crontab(5) manual, cronie cron(8) manual, cronie cron.c, Debian cron(8) manual, systemd.time(7), Kubernetes CronJob documentation, robfig/cron documentation, netresearch/go-cron issue 70, GitHub Actions: Late March 2026 updates, GitHub Actions schedule event documentation, EventBridge Scheduler schedule types.
