Waarom cronjobs misgaan bij de overgang naar zomer- of wintertijd (en hoe je dat oplost)

Het verzetten van de klok voor de zomertijd is een terugkerende deadline voor iedereen die geplande infrastructuur beheert. De EU zet de klok op 25 oktober terug en de VS volgen op 1 november, dus het loont om je cronjobs, onderhoudsvensters en on-call-roosters na te lopen voordat de volgende overgang een taak verrast. De oorzaak van bijna elke planningsbug rond zomertijd is dezelfde: iets moest draaien op een lokale kloktijd in plaats van op een vast tijdstip in UTC.

Dit is geen eenmalige ergernis. Het gebeurt twee keer per jaar, in elke tijdzone met zomertijd, en het breekt ongemerkt drie categorieën infrastructuur: geplande taken, onderhoudsvensters en alerting/on-call-roosters.

Wat er misgaat als de klok verzet wordt

Twee keer per jaar slaat de lokale tijd een uur over (de klok gaat vooruit) of herhaalt hij een uur (de klok gaat terug). Alles wat op lokale tijd is ingepland, moet dan een beslissing nemen waarvoor het meestal niet gebouwd is.

• Taken draaien twee keer of helemaal niet. Een back-uptaak die om 01:30 lokale tijd staat ingepland, wordt bij de overgang naar wintertijd twee keer uitgevoerd, omdat het die nacht twee keer 01:30 is. Bij de overgang naar zomertijd draait een taak voor 02:30 mogelijk helemaal niet, omdat dat tijdstip op de klok nooit bestaat.
• Onderhoudsvensters verschuiven een uur. Een venster gedefinieerd als "02:00–04:00 lokaal" verschuift ongemerkt ten opzichte van UTC. Een venster dat drukte overdag moet vermijden, kan daardoor midden in die drukte belanden, of een geplande deploy-freeze kan een uur te vroeg of te laat beginnen ten opzichte van alle andere systemen die nog op UTC draaien.
• On-call-overdrachten gaan mis. Roosters die in lokale tijd zijn gedefinieerd, kunnen een uur te vroeg of te laat overdragen, of de vertrekkende engineer tijdens het herhaalde uur dubbel oproepen.
• Logtijdstempels lijken terug te lopen. Als logs in lokale tijd worden geschreven, komt het uur tussen 01:00 en 02:00 in de nacht van de overgang naar wintertijd twee keer voor, waardoor je tijdens een incident onmogelijk een tijdlijn kunt reconstrueren.

Niets hiervan is een bug in cron, Kubernetes of je alertingtool. Het is wat er gebeurt als een systeem dat alleen "nu" begrijpt, rekening moet houden met een kalenderafspraak die mensen hebben bedacht voor daglicht, niet voor computers.

Waarom plannen op lokale tijd het echte probleem is

Klassieke POSIX-cron (de cron-daemon die de meeste Linux-distributies gebruiken) toetst je crontab aan de lokale tijdzone van het systeem, ingesteld via /etc/localtime. Cron kent het concept "dit uur bestaat niet" of "dit uur komt twee keer voor" niet; het controleert elke minuut alleen of de huidige kloktijd overeenkomt met je schema. Precies die ambiguïteit veroorzaakt dubbele en overgeslagen runs.

Hetzelfde probleem duikt op in beheerde schedulers. Kubernetes heeft een .spec.timeZone-veld aan CronJob toegevoegd, juist zodat schema's aan een IANA-tijdzone gekoppeld kunnen worden in plaats van aan de lokale klok van de controller. Toch waarschuwt de eigen documentatie van Kubernetes nog steeds dat een CronJob rond een zomertijdovergang twee keer kan draaien, overgeslagen kan worden of zich onverwacht kan gedragen, zelfs met een ingestelde tijdzone. Oudere AWS EventBridge-cronregels werken uitsluitend in UTC, zonder tijdzoneparameter. Dat voorkomt de ambiguïteit, maar betekent wel dat je elke regel voor "9 uur lokaal" twee keer per jaar handmatig moet bijstellen als je die ooit per ongeluk op lokale tijd hebt ingepland.

WarningStaat er in je crontab, Kubernetes CronJob of schedulerconfiguratie een opmerking als # runs at 2am local, beschouw dat dan als een zomertijdbug die op het punt staat toe te slaan. Lokale tijd in een schemadefinitie is het symptoom, niet de oplossing.

De oplossing: draai servers en schema's in UTC

Het betrouwbare patroon is eenvoudig: houd je servers, je schema's en je logs in UTC, en zet pas om naar lokale tijd op het moment dat een mens het leest. UTC kent geen zomertijd: 03:00 UTC is elke dag van het jaar 03:00 UTC, zonder ooit een herhaald of overgeslagen uur.

In de praktijk betekent dat:

• Stel de systeemtijdzone van je server in op UTC (timedatectl set-timezone UTC op Linux met systemd).
• Schrijf elke crontab-regel, Kubernetes CronJob, systemd-timer en cloud-schedulerregel in UTC.
• Sla alle logtijdstempels op in UTC (ISO 8601 met een Z-achtervoegsel, bijv. 2026-11-01T01:30:00Z) en zet ze alleen in het dashboard of de CLI-uitvoer om naar de lokale tijd van de lezer.
• Definieer onderhoudsvensters en on-call-roosters intern in UTC en toon ze in de lokale tijdzone van ieder persoon, puur als weergavelaag.

Concrete cron-voorbeelden

# Bad: local time, ambiguous twice a year
30 1 * * * /usr/local/bin/nightly-backup.sh

# Good: explicit UTC, unambiguous year-round
# (crontab itself has no time zone field — set the system/container to UTC)
TZ=UTC
30 1 * * * /usr/local/bin/nightly-backup.sh

Voor systemd-timers geldt dezelfde logica voor OnCalendar=:

[Timer]
# Runs at 01:30 UTC every day — set the unit's environment/system TZ to UTC
OnCalendar=*-*-* 01:30:00

In Kubernetes laat je timeZone leeg (dan geldt de lokale tijd van de controller; stel die host in op UTC) of stel je het expliciet in:

spec:
  schedule: "30 1 * * *"
  timeZone: "Etc/UTC"

Etc/UTC is de enige IANA-zone die gegarandeerd nooit een zomertijdovergang heeft, en precies daarom hoort hij in elke schemadefinitie die ertoe doet.

Onderhoudsvensters en on-call: dezelfde regel, andere plek

Een onderhoudsvenster of een incidentplanning op een statuspagina heeft hetzelfde soort bug als een cronjob, alleen anders uitgedrukt. Als een venster is gedefinieerd als "zaterdag 02:00–04:00 Europe/Berlin", verschuiven de onderliggende begin- en eindtijden in UTC een uur, afhankelijk van aan welke kant van de zomertijdgrens je zit. Definieer het venster in UTC en toon engineers en klanten het equivalent in lokale tijd als alleen-lezen omrekening, nooit als de opgeslagen waarde.

On-call-roosters volgen dezelfde scheiding: de grens van het rooster (wie wordt opgeroepen en wanneer het stokje wordt overgedragen) is een UTC-tijdstempel. De agendaweergave die je team bekijkt, zet die om naar de lokale tijd van ieder persoon, zodat een overdracht om 07:00 UTC wordt weergegeven als 8 of 9 uur, afhankelijk van de zone van de engineer en het seizoen, zonder dat het onderliggende schema ooit verschuift.

Korte checklist voor de overgang naar zomer- of wintertijd

Coördineer je dit voor taken, certificaten en servers bij meer dan één provider, dan is het verstandig om de planningslogica te centraliseren in plaats van twee keer per jaar een dozijn crontabs met de hand na te lopen. Lees onze gids over minder handmatig infrastructuurwerk om te zien waar je begint.

Valkuilen die het weten waard zijn

Logaggregatietools die per uur in lokale tijd groeperen, tonen in de nacht van de overgang een dubbel of ontbrekend uur, zelfs als de onderliggende tijdstempels kloppen. Controleer dus hoe je logviewer tijd groepeert, niet alleen hoe hij die opslaat. En als je alertingpipeline oproepen verstuurt via een webhook of chatintegratie, controleer dan of die integratie zelf (en niet alleen je scheduler) rekening houdt met tijdzones. Een correct ingeplande UTC-taak kan alsnog verkeerd getimed worden door een notifier verderop in de keten die van lokale tijd uitgaat.

De automations van InfraNest draaien onder de motorkap op UTC en regelen de omrekening voor weergave voor je, zodat geplande DNS-, certificaat- en servertaken geen handmatige controle twee keer per jaar nodig hebben. Bekijk het eens als je het zat bent om elke maart en november deze bug bij al je providers na te jagen.