Don’t forget DST in your schedulers, cron jobs, batch windows and settlement cut-offs

On Sunday 25 October 2026 at 03:00 CEST the EU clocks go back to 02:00 CET. The 02:00–03:00 hour of local time happens twice. Every job pinned to wall-clock time in that window will run twice, run late, or not run at all — and one of those jobs is probably a settlement cut-off.

What’s happening

The last Sunday of October is the EU’s autumn clock change, fixed by Directive 2000/84/EC. In 2026 that falls on 25 October. At 03:00 Central European Summer Time the clocks roll back to 02:00 Central European Time, so local time between 02:00 and 03:00 occurs a second time. The UK does the same thing an hour earlier: 02:00 BST becomes 01:00 GMT.

If your scheduler thinks in local wall-clock time, it does not see a smooth roll-back. It sees the same hour arrive twice. A cron entry set for 02:30 fires twice. A job set for the vanished spring-forward hour would be skipped; in autumn the risk is the double-fire. Anything downstream that assumes “this runs exactly once a night” — a reconciliation, a sweep, a payment file drop, a report — is now wrong for one night.

• Payments and settlement teams with batch windows or cut-offs that sit near 02:00–03:00 local time.
• Platform and SRE teams running cron, systemd timers or a scheduler (Airflow, Quartz, cloud cron) on local-time servers.
• Finance and reconciliation owners who trust that the nightly close ran once and only once.
• On-call rotas — whoever holds the pager that Sunday inherits every job that misbehaves.

Why it bites

A double-fired settlement or file-generation job is not a cosmetic bug. It can produce a duplicate payment instruction, a doubled ledger movement, or a second file that a counterparty ingests as new. A skipped job leaves a cut-off unmet. Either way you are reconciling by hand on a Monday, and if the job touches money someone outside the building notices first. The move to round-the-clock instant payments has thinned the quiet overnight window that used to absorb this, so there is less slack to hide in.

The one thing to do before 25 October

Set your schedulers and their host clocks to UTC, and confirm no business-critical job is anchored to a local time between 01:00 and 03:00. UTC does not observe DST, so the hour never repeats and the job runs once. If you cannot move to UTC before the date, at minimum make the affected jobs idempotent — a run key or a lock so a second trigger is a no-op — and export next run times to prove each fires once. This is one of the reasons I moved scheduled work to systemd timers, where OnCalendar and Persistent= behaviour is far easier to reason about across a clock change than a plain crontab.

If you want a second pair of hands to run the audit and harden the jobs before the date, that is exactly the kind of short, bounded delivery work my sister-brand build and operations capacity picks up — see how I work. Scope is fixed and priced per engagement, no retainer required.

Need the change made rather than just flagged? Tell me which schedulers and settlement windows are in scope and I can put delivery capacity on it well before Sunday 25 October 2026, when the hour repeats and the jobs fire whether you are ready or not.