n8n 2.45: Dein Minuten-Zeitplan läuft ab jetzt woanders los — und merkt es dir nicht

Was am 20. Oktober passiert ist

n8n 2.45 ist am 20. Oktober erschienen. Im Changelog steht ein Eintrag, der nach Infrastruktur klingt und genau deshalb überlesen wird:

„Schedule Trigger nodes now run on the durable scheduler by default, on every instance, with no environment variable to set."

Der Durable Scheduler selbst ist nicht neu. Seit 2.36 gibt es ihn, bis 2.44 musste man ihn bewusst einschalten. Seit 2.45 ist er an — auf neuen Instanzen und auf der, die bei dir seit zwei Jahren unauffällig läuft.

Dein Zutun braucht es dafür nicht. Bestehende Schedule-Trigger-Nodes wechseln laut Doku „on upgrade, without republishing". Du ziehst das neue Image, startest den Container neu, und deine komplette Zeitsteuerung steht auf einem anderen Fundament. Keine Meldung, kein Migrationsschritt, keine Rückfrage. Nebenbei entfällt in 2.45 auch die Node-Einstellung „Skip Durable Scheduler" — der Ausweg pro Workflow ist weg.

Für die meisten Setups ist das unterm Strich eine Verbesserung. Für jeden, der Zeiten koordiniert, ist es erst mal eine stille Verschiebung.

Der Satz, der deine Zeiten verschiebt

Die eigentliche Änderung steht einen Absatz weiter unten im selben Changelog-Eintrag: „every N seconds" und „every N minutes" laufen jetzt

„a steady N apart, counted from when you published the workflow."

Übersetzt: Bis 2.44 hat sich ein Minuten-Intervall an der Uhr orientiert. „Alle fünf Minuten" hieß :00, :05, :10, :15 — unabhängig davon, wann du den Workflow aktiviert hast. Ab 2.45 ist nicht mehr die Uhr der Bezugspunkt, sondern der Moment, in dem du den Workflow veröffentlicht hast.

Veröffentlichst du um 10:07:00, läuft „alle fünf Minuten" ab sofort um 10:12, 10:17, 10:22. Der Abstand stimmt weiterhin exakt. Die Uhrzeiten sind andere.

Zwei Zeitachsen untereinander. Oben, bis n8n 2.44: Läufe exakt auf den Marken :00, :05, :10, :15, :20 — an der Uhr ausgerichtet. Unten, ab n8n 2.45: Der Workflow wird um :07 veröffentlicht, die Läufe folgen um :12, :17, :22 — immer genau fünf Minuten auseinander, aber auf anderen Uhrzeiten. Merksatz: Der Takt bleibt. Der Startpunkt wandert.

Das Tückische daran ist nicht die Verschiebung selbst, sondern ihre Unsichtbarkeit. Der Workflow ist grün, die Läufe sind grün, das Intervall stimmt. Nur eben nicht mehr zur selben Minute wie gestern.

Wen das trifft — und wen nicht

Betroffen sind ausschließlich die Intervalle in Sekunden und Minuten. Alles andere verhält sich unverändert — die Doku nennt als einzige Abweichung korrektere Behandlung von Schaltjahren, 53. Kalenderwochen und Sommerzeitwechseln.

Einstellung im Schedule Trigger	Verhalten ab 2.45
Seconds	verschiebt sich — N Sekunden ab Publish
Minutes	verschiebt sich — N Minuten ab Publish
Hours	unverändert
Days	unverändert
Weeks	unverändert
Months	unverändert
Custom (Cron)	unverändert

Damit ist auch klar, wen es praktisch trifft. Wer nur „alle zehn Minuten irgendwas abholen" braucht, merkt nichts und muss nichts tun. Eng wird es dort, wo eine Minutenangabe stillschweigend als Verabredung benutzt wurde:

Workflows, die aufeinander warten. Der Import läuft „alle fünf Minuten", der Export „alle fünf Minuten, aber eine Minute später". Diese Verabredung war schon immer fragil — ab 2.45 ist sie es nachweislich, weil beide Workflows ihren eigenen Publish-Zeitpunkt mitbringen.
Jobs mit Außenwirkung zur vollen Minute. Ein Lagerabgleich, der zum Schichtbeginn fertig sein muss. Ein Preisabgleich, der vor dem Feed-Export durch ist.
Fremdsysteme mit Zeitfenstern. Schnittstellen, die nur zwischen :00 und :05 annehmen, oder ein Rate Limit, das sich an der vollen Minute zurücksetzt.

Und ein Nebeneffekt, der leicht nachhallt: Jedes Neu-Veröffentlichen setzt den Startpunkt neu. Ein Workflow, den du dienstags um 14:23 kurz änderst, läuft ab dann in einem anderen Raster als vorher.

Drei Wege, und nur einer ist dauerhaft

Custom Cron statt Minuten-Intervall. Wer feste Uhrzeiten braucht, schreibt sie hin, statt sie sich aus einem Intervall zu erhoffen. */5 * * * * läuft auf :00, :05, :10 — unter beiden Schedulern, unverändert. Das ist die einzige Variante, die auch 3.0 überlebt, und sie macht die Absicht im Workflow lesbar. Meine Empfehlung, und die einzige, die ich als Lösung bezeichnen würde.

N8N_SCHEDULER_TRIGGER_NODE_MODE=legacy. Hält die Uhrgrenzen bei, lässt den Durable Scheduler aber an. Klingt nach dem bequemen Weg und ist eine Atempause, keine Lösung: n8n hat die Variable mit 2.45 als deprecated markiert, warnt beim Start und kündigt die Entfernung an. Wer sie setzt, verschiebt dieselbe Arbeit auf einen Zeitpunkt, den er sich dann nicht mehr aussuchen kann.

N8N_SCHEDULER_ENABLED=false. Zurück in den Speicher-Scheduler, komplett. Ebenfalls deprecated, und du gibst dafür genau das auf, was im nächsten Abschnitt steht. Notbremse für den Fall, dass nach dem Upgrade etwas ernsthaft klemmt — nichts, womit man länger als ein Wochenende lebt.

Was du im Tausch bekommst

Der Durable Scheduler ist kein Selbstzweck, und der Umstieg löst ein Problem, das vorher schwer zu fassen war.

Bis 2.44 lebten anstehende Läufe im Arbeitsspeicher der Instanz. Ein Neustart zur falschen Sekunde — Deploy, OOM-Kill, Hostwartung — und der fällige Lauf war weg. Ohne Spur, denn was nie gestartet ist, taucht in keiner Liste auf. Jetzt schreibt der Scheduler jeden Lauf vor seiner Fälligkeit als Zeile in die Datenbank. Ein Neustart verliert ihn nicht mehr.

Zwei Dinge kommen dazu:

Multi-Main ohne Flaschenhals. Bisher feuerte eine Leader-Instanz alle Zeitpläne. Jetzt gilt: „one main claims each run, instead of a single leader firing them all."
Verpasste Läufe sind eine Einstellung, keine Lücke. Der Schedule Trigger hat seit 2.36 die Option If Execution Is Missed mit drei Werten: Don't Run Missed Executions (Standard), Run the Most Recent Missed Execution und Run the Most Recent Missed Execution Per Rule. Dazu Missed Execution Grace Period (Seconds); bei 0 gilt der Instanzwert N8N_SCHEDULER_MISFIRE_GRACE, standardmäßig 60 Sekunden.

Diese Optionen wirken laut Doku nur, wenn die Instanz auf dem Durable Scheduler läuft. Seit 2.45 tut sie das — womit sie für dich zum ersten Mal überhaupt greifen. Wenn du Nodes hast, bei denen ein nachgeholter Lauf schadet (alles, was Mails verschickt oder Geld bewegt), ist der Standardwert der richtige. Aber jetzt ist es eine Entscheidung und kein Zufall mehr.

Der Fall, in dem gar nichts passiert

Es gibt einen zweiten Weg, auf dem Zeitsteuerung scheitert, und der ist deutlich unangenehmer als eine Verschiebung um sieben Minuten.

Im n8n-Tracker liegt ein offener Fall dazu: Schedule-Workflows stehen auf aktiv, lassen sich von Hand einwandfrei starten, erzeugen aber null automatische Ausführungen. Ursache war, dass die betroffenen Workflows im Publication Service fehlten und der Scheduler deshalb keine scheduled_job-Einträge anlegte. Der Satz aus der Analyse beschreibt das Problem besser als jede Umschreibung:

„No error logging occurs; silence is the only symptom."

Genau hier bricht die Absicherung, auf die sich die meisten verlassen. Ein Error Workflow hängt an einer fehlgeschlagenen Ausführung. Kein Lauf heißt keine Ausführung, keine Ausführung heißt kein Fehler — und etwas, das nie gestartet ist, kann nicht fehlschlagen. Dein Monitoring meldet, dass alles in Ordnung ist, weil es nichts findet, was nicht in Ordnung wäre.

Der erste Griff nach einem Upgrade ist deshalb nicht der Workflow-Editor, sondern die Frage, ob seitdem überhaupt etwas gelaufen ist:

GET /api/v1/executions?workflowId=aBcD1234&status=success&limit=1
X-N8N-API-KEY: dein-api-key

Der Mengenwächter

Daraus wird ein Wächter, und sein Prinzip ist der ganze Unterschied: Er prüft nicht, ob ein Lauf fehlgeschlagen ist, sondern ob überhaupt einer stattgefunden hat.

Variante A, zentral und ohne Eingriff. Ein einziger Workflow hält eine Liste der überwachten Workflow-IDs samt erlaubter Höchstpause, ruft für jede den Aufruf von oben ab und schlägt an, wenn der jüngste Lauf zu alt ist oder gar keiner existiert.

Ein Detail, über das man in der API-Doku stolpert: GET /executions filtert nach status, workflowId, limit und cursor — einen Zeitraum-Filter gibt es nicht. Du zählst also nicht „Läufe der letzten Stunde", sondern holst dir mit limit=1 den jüngsten und siehst dir sein startedAt an. Für die Frage „lebt das noch?" reicht das vollständig:

const letzter = $json.data?.[0];
if (!letzter) {
  return [{ json: { alarm: true, grund: 'Noch nie erfolgreich gelaufen' } }];
}
const minutenHer = (Date.now() - new Date(letzter.startedAt)) / 60000;
return [{ json: { alarm: minutenHer > $json.maxPause, minutenHer } }];

Der Vorteil: Du fasst keinen einzigen überwachten Workflow an, und genau der Fall von oben wird erkannt — wenn die Ausführungen komplett fehlen, ist das Ergebnis leer statt alt.

Variante B, wenn „lief" nicht genug ist. Manche Workflows laufen pünktlich und tun trotzdem nichts, weil die Quelle leer blieb oder ein Filter zu scharf steht. Dann schreibt jeder Workflow am Ende eine Zeile per Data Table — Workflowname, Zeitstempel, verarbeitete Menge — und der Wächter prüft nicht nur das Alter, sondern auch die Zahl. Das ist dieselbe Mechanik, die ich schon beim Merker gegen Doppel-Mails in der Zahlungserinnerung benutze.

Und der Punkt, ohne den das Ganze wertlos ist: Der Wächter darf nicht auf dem Scheduler hängen, den er überwacht. Ein Wächter-Workflow mit Schedule Trigger auf derselben Instanz fällt im Ernstfall mit aus und schweigt mit. Er gehört an einen externen Auslöser — ein Cron auf einem anderen Host, der seinen Webhook aufruft, oder der Healthcheck, den du ohnehin schon hast.

Was nach 2.45 kommt

n8n hat 3.0.0 für den 27. Oktober angekündigt, stable für Anfang Dezember. Freigegeben ist es damit noch nicht: Das Image n8nio/n8n:3.0.0 existiert und läuft, latest zeigt aber weiter auf die 2er-Linie. Zwei Punkte daraus betreffen genau dieses Thema: Cron und Interval werden entfernt, Ersatz ist der Schedule Trigger. Und der Legacy-Modus, der dir oben die Uhrgrenzen zurückgeben würde, ist bereits zum Abschuss freigegeben.

Wer jetzt auf Custom Cron umstellt, erledigt beide Baustellen in einem Durchgang. Die vollständige Liste dessen, was 3.0 sonst noch anfasst, führt n8n in den v3.0 Breaking changes. Was der mitgelieferte Migration Report davon übersieht, habe ich in Fünf Dinge, die der Migration Report dir nicht sagt gegen 3.0.0 nachgemessen.

Fazit

Die Kurzfassung in drei Sätzen:

Der Takt bleibt, der Startpunkt wandert. Betroffen sind nur Sekunden- und Minuten-Intervalle, und spürbar wird es nur dort, wo Zeiten koordiniert sind. Prüfe diese Workflows, nicht alle.
Custom Cron statt Legacy-Variable. Beides stellt die alten Uhrzeiten her, aber nur eines überlebt 3.0.
Ein Wächter, der zählt, fängt beide Fälle ab. Die Verschiebung und das Totalschweigen. Ein Error Workflow kann das nicht, weil er einen Fehler braucht — und der ausbleibende Lauf liefert keinen.

Wenn du nach dem Upgrade nicht sicher sagen kannst, wann deine zeitgesteuerten Workflows zuletzt gelaufen sind, ist das die Antwort auf die Frage, womit du anfängst.

→ Zum Kontaktformular