Die Zeitumstellung zwischen Sommer- und Winterzeit ist eine wiederkehrende Deadline für alle, die geplante Infrastruktur betreiben. Die EU stellt die Uhren am 25. Oktober zurück, die USA folgen am 1. November. Es lohnt sich also, deine Cronjobs, Wartungsfenster und On-Call-Pläne zu prüfen, bevor die nächste Umstellung einen Job kalt erwischt. Die Ursache fast jedes Planungsfehlers rund um die Sommerzeit ist dieselbe: Etwas soll zu einer lokalen Uhrzeit laufen statt zu einem festen Zeitpunkt in UTC.
Das ist kein einmaliges Ärgernis. Es passiert zweimal im Jahr, in jeder Zeitzone mit Sommerzeit, und legt still und leise drei Bereiche der Infrastruktur lahm: geplante Jobs, Wartungsfenster und Alerting bzw. On-Call-Rotationen.
Was bei der Zeitumstellung tatsächlich kaputtgeht
Zweimal im Jahr fällt in der Ortszeit entweder eine Stunde weg (Uhr vorstellen) oder eine Stunde wiederholt sich (Uhr zurückstellen). Alles, was nach Ortszeit geplant ist, muss dann eine Entscheidung treffen, für die es meist nicht gebaut wurde.
- Jobs laufen doppelt oder gar nicht. Ein Backup-Job, der auf 01:30 Uhr Ortszeit eingestellt ist, startet beim Zurückstellen der Uhr zweimal, weil es in dieser Nacht zweimal 01:30 Uhr wird. Beim Vorstellen der Uhr startet ein Job für 02:30 Uhr womöglich nie, weil es diese Uhrzeit schlicht nicht gibt.
- Wartungsfenster verschieben sich um eine Stunde. Ein Fenster, das als „02:00–04:00 Ortszeit“ definiert ist, verschiebt sich unbemerkt gegenüber UTC. Ein Fenster, das eigentlich den Tagesverkehr meiden soll, landet dann mitten darin, oder ein geplanter Deploy-Freeze beginnt eine Stunde zu früh oder zu spät im Vergleich zu allen anderen Systemen, die weiter auf UTC laufen.
- On-Call-Übergaben gehen schief. Rotationen, die in Ortszeit definiert sind, übergeben eine Stunde zu früh oder zu spät oder alarmieren die abgebende Person in der wiederholten Stunde doppelt.
- Log-Zeitstempel scheinen rückwärts zu laufen. Werden Logs in Ortszeit geschrieben, taucht die Stunde zwischen 01:00 und 02:00 Uhr in der Nacht der Rückstellung zweimal auf. Bei einem Incident lassen sich Zeitabläufe dann nicht mehr rekonstruieren.
Nichts davon ist ein Bug in cron, Kubernetes oder deinem Alerting-Tool. Es passiert einfach, wenn ein System, das nur „jetzt“ kennt, eine Kalenderkonvention beachten soll, die Menschen für das Tageslicht erfunden haben und nicht für Computer.
Warum Planung nach Ortszeit das eigentliche Problem ist
Das klassische POSIX-cron (der cron-Daemon der meisten Linux-Distributionen) wertet deine Crontab anhand der lokalen Zeitzone des Systems aus, die über /etc/localtime festgelegt ist. Es kennt weder „diese Stunde gibt es nicht“ noch „diese Stunde kommt zweimal vor“. Es prüft einfach jede Minute, ob die aktuelle Uhrzeit zu deinem Zeitplan passt. Genau diese Mehrdeutigkeit führt zu doppelten und ausgelassenen Läufen.
Dasselbe Problem zeigt sich bei verwalteten Schedulern. Kubernetes hat CronJob eigens das Feld .spec.timeZone hinzugefügt, damit sich Zeitpläne an eine IANA-Zeitzone statt an die lokale Uhr des Controllers binden lassen. Trotzdem warnt die Kubernetes-Dokumentation selbst, dass ein CronJob rund um eine Zeitumstellung doppelt laufen, ausgelassen werden oder sich unerwartet verhalten kann, auch wenn eine Zeitzone gesetzt ist. Die älteren Cron-Regeln von AWS EventBridge arbeiten ausschließlich in UTC und haben gar keinen Zeitzonen-Parameter. Das vermeidet zwar die Mehrdeutigkeit, bedeutet aber, dass jede „9 Uhr Ortszeit“-Regel zweimal im Jahr von Hand verschoben werden muss, falls du sie versehentlich nach Ortszeit geplant hast.
WarningWenn deine Crontab, dein Kubernetes-CronJob oder deine Scheduler-Konfiguration einen Kommentar wie
# runs at 2am localenthält, betrachte das als Sommerzeit-Bug, der nur darauf wartet, zuzuschlagen. Ortszeit in einer Zeitplandefinition ist das Warnsignal, nicht die Lösung.
Die Lösung: Server und Zeitpläne in UTC betreiben
Das zuverlässige Muster ist einfach: Halte deine Server, Zeitpläne und Logs in UTC und rechne erst dann in Ortszeit um, wenn ein Mensch sie liest. UTC kennt keine Sommerzeit: 03:00 UTC ist an jedem Tag des Jahres 03:00 UTC, ganz ohne wiederholte oder ausgelassene Stunde.
Praktisch heißt das:
- Stelle die Systemzeitzone deiner Server auf UTC (
timedatectl set-timezone UTCauf systemd-basiertem Linux). - Schreibe jeden Crontab-Eintrag, jeden Kubernetes-CronJob, jeden systemd-Timer und jede Cloud-Scheduler-Regel in UTC.
- Speichere alle Log-Zeitstempel in UTC (ISO 8601 mit
Z-Suffix, z. B.2026-11-01T01:30:00Z) und rechne erst im Dashboard oder in der CLI-Ausgabe in die Ortszeit der betrachtenden Person um. - Definiere Wartungsfenster und On-Call-Rotationen intern in UTC und zeige sie jeder Person rein als Anzeigeebene in ihrer eigenen Zeitzone an.
Konkrete Cron-Beispiele
# 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
Für systemd-Timer gilt dieselbe Logik für OnCalendar=:
[Timer]
# Runs at 01:30 UTC every day — set the unit's environment/system TZ to UTC
OnCalendar=*-*-* 01:30:00
Bei Kubernetes lässt du timeZone entweder ungesetzt (dann gilt die Ortszeit des Controllers – stelle diesen Host auf UTC) oder setzt es explizit:
spec:
schedule: "30 1 * * *"
timeZone: "Etc/UTC"
Etc/UTC ist die einzige IANA-Zone, bei der garantiert nie eine Zeitumstellung stattfindet. Genau deshalb gehört sie in jede wichtige Zeitplandefinition.
Wartungsfenster und On-Call: gleiche Regel, andere Oberfläche
Ein Wartungsfenster oder ein geplanter Incident auf einer Statusseite hat dieselbe Fehlerklasse wie ein Cronjob, nur anders ausgedrückt. Ist ein Fenster als „Samstag 02:00–04:00 Europe/Berlin“ definiert, verschieben sich die zugrunde liegenden Start- und Endzeiten in UTC um eine Stunde, je nachdem, auf welcher Seite der Zeitumstellung du dich befindest. Definiere das Fenster in UTC und zeige Engineers und Kund:innen die Ortszeit nur als schreibgeschützte Umrechnung an – niemals als gespeicherten Wert.
On-Call-Rotationen folgen derselben Aufteilung: Die Grenze der Rotation (wer alarmiert wird und wann der Staffelstab weitergegeben wird) ist ein UTC-Zeitstempel. Die Kalenderansicht deines Teams rechnet ihn in die Ortszeit jeder Person um, sodass eine Übergabe um 07:00 UTC je nach Zeitzone und Jahreszeit als 8 oder 9 Uhr erscheint, ohne dass sich der zugrunde liegende Plan jemals verschiebt.
Kurze Checkliste vor der Zeitumstellung
| Prüfpunkt | Warum das wichtig ist |
|---|---|
| Zeitzone von Server/Container ist UTC | Beseitigt Mehrdeutigkeit bei jedem Zeitplan, der dort läuft |
| Crontab-/CronJob-/Timer-Einträge nutzen UTC, nicht die lokale Uhrzeit | Vermeidet die wiederholte bzw. ausgelassene Stunde komplett |
Logs speichern UTC-Zeitstempel (ISO 8601 Z) |
Hält Incident-Zeitabläufe über die Umstellung hinweg in Ordnung |
| Wartungsfenster in UTC gespeichert, in Ortszeit angezeigt | Fenstergrenzen verschieben sich nicht gegenüber den realen Traffic-Mustern |
| Grenzen der On-Call-Rotation in UTC gespeichert | Übergaben finden jedes Mal zum selben realen Zeitpunkt statt |
Wenn du das über Jobs, Zertifikate und Server bei mehreren Anbietern hinweg koordinierst, lohnt es sich, die Planungslogik zu zentralisieren, statt zweimal im Jahr ein Dutzend Crontabs von Hand zu prüfen. In unserem Leitfaden zum Reduzieren manueller Infrastrukturarbeit erfährst du, wo du anfangen kannst.
Weitere Stolperfallen, die du kennen solltest
Log-Aggregations-Tools, die nach Stunden in Ortszeit gruppieren, zeigen in der Nacht der Umstellung eine doppelte oder fehlende Stunde an, selbst wenn die zugrunde liegenden Zeitstempel korrekt sind. Prüfe also, wie dein Log-Viewer Zeit gruppiert, nicht nur, wie er sie speichert. Und wenn deine Alerting-Pipeline über einen Webhook oder eine Chat-Integration alarmiert, stelle sicher, dass auch die Integration selbst (nicht nur dein Scheduler) Zeitzonen korrekt behandelt. Ein sauber in UTC geplanter Job kann trotzdem falsch getimt werden, wenn ein nachgelagerter Benachrichtigungsdienst Ortszeit annimmt.
Die Automatisierungen von InfraNest laufen intern auf UTC und übernehmen die Umrechnung für die Anzeige. Geplante DNS-, Zertifikats- und Server-Aufgaben brauchen also keine manuelle Prüfung zweimal im Jahr. Schau es dir an, wenn du es leid bist, diesem Bug jeden März und November über mehrere Anbieter hinweg hinterherzujagen.
Häufig gestellte Fragen
#Macht die Umstellung der Server-Zeitzone auf UTC etwas anderes kaputt?
Nein – Anwendungen sollten Zeitstempel intern ohnehin schon in UTC speichern und vergleichen. Wenn du die Zeitzone des Betriebssystems auf UTC stellst, entfällt nur eine unnötige Umrechnung in Ortszeit, und cron, Logs und Timer werden eindeutig.
#Unterstützt cron Zeitzonen direkt?
Das klassische POSIX-cron hat überhaupt kein Zeitzonenfeld. Es wertet deinen Zeitplan einfach anhand der lokalen Systemzeit aus. Deshalb solltest du das System (oder den Container) auf UTC stellen, statt zu versuchen, eine Zeitzone in der Crontab anzugeben.
#Löst das timeZone-Feld des Kubernetes-CronJobs das Problem vollständig?
Damit kannst du einen Zeitplan an eine bestimmte IANA-Zone wie Etc/UTC binden. Die Kubernetes-Dokumentation warnt aber selbst, dass Jobs in anderen Zonen genau an der Zeitumstellung doppelt laufen oder ausgelassen werden können. UTC als Zone bleibt daher die sicherste Wahl.
#Was ist die einfachste erste Maßnahme, wenn ich nicht alles auf einmal umstellen kann?
Fang mit allem an, was zwischen Mitternacht und 3 Uhr Ortszeit läuft, denn in diesem Zeitfenster wiederholen sich Stunden oder fallen weg. Stelle diese Jobs zuerst auf explizite UTC-Zeitpläne um und arbeite dich dann durch den Rest.
War dieser Artikel hilfreich?
