Zeitzonen-Bugs: warum produktive Automatisierungen sonntags um drei Uhr morgens kollabieren

Zeitzonen-Bugs sind die heimtückischsten Fehler in produktiven Automatisierungen

Letzten Sonntag um 03:14 Uhr leuchtete ein Slack-Alert auf. Bei einem Kunden hatte ein Rechnungs-Workflow 47 Mahnungen mehr verschickt, als er sollte. Empfänger in Frankfurt, Wien und New York. Auslöser: eine harmlose Zeitumstellung in der vorangegangenen Nacht.

Solche Anrufe kennen wir. Sie kommen am Wochenende, niemand versteht zunächst, warum ein Workflow, der seit acht Monaten sauber lief, plötzlich kollabiert. Die Ursache lässt sich in fast allen Fällen auf drei Buchstaben verkürzen: UTC.

In den letzten zwei Jahren haben wir mehr Automatisierungen wegen Zeitzonen-Fehlern repariert als wegen echter API-Ausfälle. Diese Bugs sind schwerer zu finden, schwerer nachzustellen, und sie kosten in der Reparatur fast immer mehr, als der Aufbau der Automatisierung ursprünglich kostete.

Das Problem ist nicht die Zeit, sondern die Daten

Jede Plattform behandelt Datumsfelder anders. Make speichert Workflow-Zeitpläne in der Zeitzone des Workspace-Owners. n8n läuft per Default in UTC, lässt sich aber pro Workflow überschreiben. Zapier nutzt die Account-Zeitzone, aber eingehende Webhook-Payloads bringen ihre eigene Zeitzone mit. HubSpot liefert Datumsfelder in UTC und zeigt sie in der Lokalzeit des angemeldeten Users. Salesforce speichert in UTC, exportiert je nach Org-Einstellung anders.

Nichts davon ist versteckt. Alles ist dokumentiert. Aber niemand liest die Dokumentation, bevor der erste Bug auftaucht. Und dann läuft die Automatisierung schon seit Monaten produktiv.

Der Bug ist nicht, dass Plattformen sich über Zeit uneinig sind. Der Bug ist, dass der Workflow annimmt, sie wären sich einig.

Drei Stellen, an denen diese Bugs sich verstecken

Wir sehen immer wieder dieselben drei Muster.

Tagesgrenzen. Ein Workflow läuft jeden Abend um 23:55 Uhr und verarbeitet "alle Tickets von heute". Der Server steht in UTC. Das Team sitzt in Berlin. Im Sommer sind das zwei Stunden Versatz. Wenn der Workflow in UTC startet, ist es bereits nach Mitternacht UTC, der Filter "Tickets von heute" verfehlt also alles, was zwischen 22:00 und 23:55 Berlin-Zeit erstellt wurde. Sechs Stunden Daten, ohne Fehlermeldung verschwunden.

Sommer- und Winterzeitumstellung. Zweimal pro Jahr springt Europa um eine Stunde. Manche Plattformen handhaben das in ihrer Cron-Logik automatisch. Manche nicht. Ein Workflow, der "jeden Werktag um 9 Uhr" feuern soll, läuft nach der Umstellung um 8 Uhr, oder überspringt einen Tag, je nachdem, wie der Scheduler den Offset interpretiert.

Internationale Empfänger. Sie schicken eine Erinnerungsmail mit dem Text "Ihr Termin ist morgen um 14 Uhr". Der Empfänger sitzt in Tokio. Wenn er die Mail öffnet, ist "morgen" dort schon heute, und Ihre "14 Uhr" liegen je nach Datum zwischen 21 Uhr seiner Zeit und 4 Uhr am Folgetag. Wir hatten Fälle, in denen Kunden aus Diensten ausgesperrt wurden, weil die Automatisierung "heute" als Serverzeit definiert hatte, nicht als Kundenzeit.

Die drei Regeln, die wir vor jedem Go-Live einfordern

Bevor ein Workflow bei uns produktiv geht, müssen drei Punkte explizit geklärt sein.

Regel 1: Alles in UTC speichern. Egal ob Datenbank, CRM-Feld oder Tabelle. Der kanonische Zeitstempel ist UTC. Konvertiert wird nur an der Anzeige-Oberfläche oder beim Versenden in die User-Zeitzone. Diese eine Regel verhindert den größten Teil der Probleme, die wir sehen.

Regel 2: Niemals einen Cron-Job ohne explizite Zeitzone. "9 Uhr" ist mehrdeutig. "9 Uhr Europe/Berlin" ist es nicht. Make, n8n und Zapier unterstützen alle Zeitzonen-bewusstes Scheduling, und alle drei haben unterschiedliche Defaults. Wer keine explizite Zeitzone wählt, verlässt sich auf den Default. Der Default ändert zweimal im Jahr etwas.

Regel 3: Tagesgrenzen als Ranges, nicht als Magie. Wenn der Workflow "Termine von morgen" lädt, schreiben Sie nicht `created_at = today() + 1`. Schreiben Sie `created_at >= [Start morgen in UTC] AND created_at < [Ende morgen in UTC]`. Die Rechnung ist nervig, das Ergebnis ist korrekt.

Ein 15 Minuten Audit, das Sie heute durchführen können

Nehmen Sie sich Ihre fünf wichtigsten Automatisierungen vor und beantworten Sie pro Workflow drei Fragen.

Erstens: In welcher Zeitzone läuft der Trigger? Verlassen Sie sich nicht auf die UI. Schauen Sie in die Logs. Make zeigt die Workspace-Zeitzone rechts oben. n8n zeigt sie in den Workflow-Settings. Zapier zeigt sie im Account-Profil. Notieren Sie es.

Zweitens: Welches Format haben die Datumsfelder, die rein- und rausgehen? Vergleichen Sie zwei Datensätze in der Quell-Plattform mit dem, was im Zielsystem ankommt. Wenn die Werte leicht abweichen, haben Sie einen stillen Zeitzonen-Bug.

Drittens: Was passiert bei der nächsten Zeitumstellung? In der EU fällt sie auf den 25. Oktober 2026. Tragen Sie sich den Tag im Kalender ein. Am Morgen danach prüfen Sie alle zeitgesteuerten Workflows. Wir machen das jedes Jahr. Jedes Jahr finden wir mindestens eine Automatisierung, die einen manuellen Eingriff braucht.

Warum diese Bugs in keinem Testlauf auftauchen

Weil sie sich in der Zeit selbst verstecken. Ein Workflow mit Sommerzeit-Bug ist exakt zwei Tage im Jahr defekt. Ein Workflow mit Tagesgrenzen-Bug bricht nur bei Datensätzen nahe Mitternacht, das ist meistens weniger als ein Prozent des Volumens. Ein Workflow mit Empfänger-Zeitzonen-Bug versagt nur, wenn ein bestimmter User aus einer bestimmten Zeitzone in einem bestimmten Zeitfenster handelt.

Standard-QA fängt nichts davon ab. Stage-Umgebungen laufen auf Serverzeit. Manuelle Tests laufen während der Bürozeiten. Niemand plant Tests für 02:00 Uhr am letzten Sonntag im Oktober.

Wer Datumsfelder, Zeitpläne oder internationale Empfänger in seinen Automatisierungen hat, hat diese Bugs. Die Frage ist nur, ob er sie kennt, und ob er sie findet, bevor der nächste Slack-Alert um drei Uhr morgens kommt.

Wenn Sie unsicher sind, welche Ihrer Workflows diese Lücken haben, lohnt sich ein Blick in unseren kostenlosen Automations-Check. Wir gehen die Liste mit Ihnen durch und priorisieren, welche Workflows als erstes abgesichert werden sollten.