Cron und Schedule Trigger in n8n richtig konfigurieren: Die Zeitzone ist fast immer schuld

Der Cron-Ausdruck im Schedule Trigger stimmt fast immer. Was in der Praxis meistens nicht stimmt, ist die Zeitzone, in der n8n diesen Ausdruck auswertet. Genau dieses Muster zieht sich durch drei echte Threads im n8n-Forum, die wir uns in diesem Artikel im Detail ansehen: ein Team im Queue-Mode, ein Nutzer in Brasilien und ein Nutzer in London, der sich über eine Stunde Differenz wunderte, obwohl seine Workflow-Einstellung auf GMT stand. In allen drei Fällen war der Cron-Ausdruck selbst korrekt, die Ursache lag jeweils eine Ebene tiefer.

Laut der offiziellen Dokumentation zum Schedule Trigger nutzt der Node eine Zeitzonen-Hierarchie mit mehreren Ebenen, und genau an dieser Stelle entstehen die meisten Überraschungen. Wenn du verstehst, wie n8n diese Ebenen auflöst, lassen sich fast alle Zeitzonen-Bugs vermeiden, bevor sie überhaupt live gehen. Stand: Juli 2026.

Wie der Schedule Trigger Cron-Ausdrücke interpretiert

Im Custom-Modus akzeptiert der Schedule Trigger laut Doku einen klassischen Cron-Ausdruck mit sechs Feldern, wobei das sechste, optionale Feld die Sekunden abbildet, gefolgt von Minute, Stunde, Tag im Monat, Monat und Wochentag. Die Dokumentation listet dazu eine Referenztabelle mit gängigen Mustern:

• Alle X Sekunden: `*/10 * * * * *`
• Alle X Minuten: `*/5 * * * *`
• Stündlich: `0 * * * *`
• Täglich: `0 6 * * *`
• Wöchentlich: `0 12 * * 1`
• Monatlich: `0 0 1 * *`

Zum Testen empfiehlt n8n selbst, einen Ausdruck vorher auf crontab.guru zu prüfen, allerdings ohne die optionale Sekundenspalte, weil dieses Tool nur fünf Felder kennt. Genau dieser Schritt hilft dir, syntaktische Fehler auszuschließen, bevor du überhaupt in die Zeitzonen-Fallstricke einsteigst. Der Ausdruck selbst ist in fast jedem der öffentlich diskutierten Probleme unauffällig, das Problem beginnt erst danach, bei der Frage, in welcher Zeitzone n8n diesen Ausdruck überhaupt auswertet.

Die Zeitzonen-Hierarchie: Instance, Workflow und Worker

n8n legt für die Zeitzone eine klare Rangfolge fest. Ist im Workflow selbst eine Zeitzone gesetzt, gilt diese. Fehlt sie, greift n8n auf die Instance-Zeitzone zurück. Bei selbst gehosteten Instanzen ist der Standardwert dabei nicht etwa UTC oder die Zeitzone deines Servers, sondern laut Dokumentation `America/New_York`. Bei n8n Cloud versucht das System, die Zeitzone des Kontoinhabers automatisch zu erkennen, fällt bei fehlgeschlagener Erkennung aber auf GMT zurück.

Die Seite zu häufigen Problemen des Schedule Trigger beschreibt genau diesen Mechanismus als häufigste Fehlerquelle und nennt zwei Stellschrauben: Auf Workflow-Ebene lässt sich die Zeitzone über die drei Punkte oben rechts im Canvas, dann Settings und den Parameter Timezone anpassen. Global für die ganze Instanz setzt du bei selbst gehosteten Installationen stattdessen die Umgebungsvariable `GENERIC_TIMEZONE`. Wichtig dabei: Diese Variable wirkt auf die Instanz, nicht automatisch auf jeden einzelnen Prozess, der zu dieser Instanz gehört, wie der erste Fall unten zeigt.

Drei echte Fälle aus dem n8n-Forum

Fall 1: Queue Mode, korrekt konfiguriert, trotzdem falsch

Im Thread „Schedule Trigger executing at wrong time" beschreibt ein Nutzer einen wöchentlichen Trigger, der sonntags um 3 Uhr PST laufen sollte, tatsächlich aber um 19 Uhr auslöste. Sowohl die Workflow-Einstellung als auch die Installationszeitzone standen korrekt auf PST, ein alter Cron-Node lief sogar parallel fehlerfrei. Die Lösung fand der Nutzer selbst: „We use n8n in queue mode - and it turns out, I forgot to set the timezone parameters on the workers!!!" Die Hauptinstanz hatte die richtige Zeitzone, die separaten Worker-Pods in Kubernetes aber nicht. Nach Setzen der TZ-Umgebungsvariable auf den Worker-Deployments lief der Test-Workflow „on the dot", wie der Nutzer bestätigt. Wer n8n im Queue Mode betreibt, muss die Zeitzone also auf jeder einzelnen Komponente setzen, nicht nur auf der Hauptinstanz.

Fall 2: Brasilien und der stille Standardwert

Im Thread „Schedule Trigger - what's the time zone?" meldet ein Nutzer aus Brasilien (UTC-3) eine Differenz von genau zwei Stunden: Ein für 11 Uhr geplanter Trigger lief stattdessen um 13 Uhr. Die Ursache war schlicht der nicht überschriebene Standardwert `America/New_York`, den n8n bei selbst gehosteten Instanzen ansetzt, wenn niemand explizit etwas anderes konfiguriert. Als Lösung wurden zwei Wege genannt, entweder die Zeitzone direkt im Workflow über die Settings zu ändern oder global per `GENERIC_TIMEZONE` in der Docker-Compose-Datei beziehungsweise im Docker-Image zu setzen. Wer eine frische n8n-Installation aufsetzt, sollte diese Variable also von Anfang an mitdenken, statt sie erst nach dem ersten falsch ausgelösten Trigger nachzutragen.

Fall 3: London, Sommerzeit und das Missverständnis rund um GMT

Im Thread „Schedule Trigger and Confusion Over Time Zone Settings" wunderte sich Nutzer kpakfar über eine Stunde Differenz zwischen `DateTime.now()`, das korrekt die Londoner Zeit inklusive Sommerzeit anzeigte, und dem Schedule Trigger, der scheinbar nach der als GMT bezeichneten Einstellung lief. Community-Mitglied ihortom stellte klar, dass der Trigger korrekt nach Londoner Zeit arbeitete, nicht nach der wörtlichen Bezeichnung „GMT 00:00". Der Hinweis dazu: Wer wirklich eine feste Zeitzone ohne Sommerzeit-Umstellung will, muss explizit „(GMT+00:00) GMT (no daylight saving)" auswählen. Die normale, mit einer Stadt verknüpfte Zeitzonen-Option berücksichtigt die Sommerzeit automatisch, auch wenn ihr Label das nicht auf den ersten Blick verrät. Wer feste UTC-Zeiten unabhängig von Sommerzeit braucht, etwa für Systeme, die selbst UTC sprechen, sollte gezielt die Variante ohne Sommerzeit wählen statt einer städtebasierten Zeitzone.

So richtest du die Zeitzone verlässlich ein

• Cron-Ausdruck getrennt prüfen: Teste die reine Syntax vorab auf crontab.guru, ohne das optionale Sekundenfeld, bevor du dich um die Zeitzone kümmerst.
• Workflow-Zeitzone explizit setzen: Verlasse dich nicht auf den Instanz-Standard, sondern trage die Zeitzone in den Workflow-Settings ein, besonders bei mehreren Workflows mit unterschiedlichen Zielgruppen oder Ländern.
• `GENERIC_TIMEZONE` bei Self-Hosting setzen: Ohne diese Variable steht deine Instanz auf `America/New_York`, unabhängig davon, wo dein Server tatsächlich läuft.
• Queue Mode: Worker nicht vergessen: Setze die Zeitzone auf jedem Worker-Deployment einzeln, eine korrekte Hauptinstanz reicht dort nicht aus.
• Sommerzeit bewusst entscheiden: Wähle eine städtebasierte Zeitzone, wenn die Sommerzeit automatisch mitlaufen soll, oder eine feste Variante ohne Sommerzeit, wenn du unabhängig von Jahreszeiten eine exakte UTC-Zeit brauchst.

Bei NordFlux richten wir n8n-Workflows so ein, dass Cron-Trigger von Anfang an in der richtigen Zeitzone laufen, egal ob auf einer einzelnen Instanz oder im Queue Mode mit mehreren Workern. So bleiben zeitkritische Automatisierungen zuverlässig, und du behältst die Kontrolle darüber, wann deine digitalen Mitarbeiter tatsächlich anspringen. Mehr zu unserer Herangehensweise findest du unter n8n-Automatisierung von NordFlux.

Häufige Fragen

Warum läuft mein Cron-Trigger zur falschen Zeit, obwohl der Ausdruck korrekt ist?

In den allermeisten Fällen liegt es nicht am Cron-Ausdruck selbst, sondern an der Zeitzone, in der n8n ihn auswertet. Prüfe zuerst die Workflow-Settings, dann die Instanz-Zeitzone und im Queue Mode zusätzlich die Zeitzone auf jedem Worker.

Was ist die Standard-Zeitzone von n8n, wenn ich nichts einstelle?

Bei selbst gehosteten Instanzen ist der Standardwert laut Dokumentation `America/New_York`. Bei n8n Cloud versucht das System, die Zeitzone automatisch zu erkennen, und weicht bei fehlgeschlagener Erkennung auf GMT aus. Beide Standardwerte stimmen selten zufällig mit deiner tatsächlichen Zeitzone überein.

Wie stelle ich die Zeitzone für einen einzelnen Workflow ein?

Öffne den Workflow im Canvas, klicke oben rechts auf die drei Punkte, wähle Settings und passe den Parameter Timezone an. Diese Einstellung überschreibt die Instanz-Zeitzone nur für diesen einen Workflow.

Muss ich im Queue Mode zusätzlich etwas beachten?

Ja. Die Zeitzonen-Einstellung der Hauptinstanz reicht im Queue Mode nicht aus, weil Trigger auf separaten Worker-Prozessen ausgeführt werden. Setze die passende TZ-Umgebungsvariable auf jedem Worker-Deployment, sonst kann die Hauptinstanz korrekt konfiguriert sein und der Trigger trotzdem zur falschen Zeit auslösen.

Wie vermeide ich Überraschungen durch die Sommerzeit?

Eine städtebasierte Zeitzone wie London oder Berlin passt sich automatisch an Sommer- und Winterzeit an. Willst du stattdessen eine feste Zeit unabhängig von der Jahreszeit, wähle explizit eine Zeitzonen-Option ohne Sommerzeit, statt dich auf das Label allein zu verlassen.