n8n-Schedule-Trigger läuft nach Neustart nicht mehr
Das Symptom ist leise: Der Workflow gilt als aktiv, die Instanz antwortet normal, und die Ausführungsliste hört einfach am Tag des letzten Neustarts auf. Nichts ist fehlgeschlagen, also wurde nichts gemeldet. Bemerkt wird es meist von dem, der auf das Ergebnis gewartet hat – in der Agenturarbeit ist das der Kunde.
Step 1
Confirm it is the trigger, not the logic
Öffne den Workflow und starte ihn von Hand. Läuft er durch, ist der Workflow in Ordnung und der Trigger wurde nie scharf geschaltet. Schlägt der Handlauf fehl, hast du einen gewöhnlichen Fehler, und die Ausführungsliste zeigt ihn.
Step 2
Look at the last execution, not the status
„Aktiv“ ist ein gespeichertes Kennzeichen, kein Versprechen, dass etwas eingeplant ist. Das ehrliche Signal ist der Zeitstempel der letzten Ausführung gegen das Intervall, in dem der Workflow laufen sollte. Ein täglicher Workflow, dessen letzter Lauf vier Tage her ist, steht – egal was das Abzeichen sagt.
Step 3
Re-arm it
Schalte den Workflow aus und wieder ein. Das registriert den Trigger neu und ist meistens die ganze Lösung. Steht er nach dem nächsten Neustart wieder, sieh nach, ob die Instanz mitten in der Registrierung gestoppt wird – und in die Zeitzoneneinstellungen: Ein Zeitplan in einer anderen Zeitzone kann stehengeblieben aussehen, obwohl er sich nur verschoben hat.
Warum dich nichts gewarnt hat
Ein Error-Workflow feuert nur, wenn eine Ausführung läuft und scheitert. Hier lief nichts, also gab es keinen Fehler zu melden und keine Nachricht zu schicken. Das ist keine Fehlkonfiguration – dafür sind Error-Workflows da. Die Lücke schließt eine ganz andere Prüfung: den letzten Lauf jedes Workflows gegen sein erwartetes Intervall halten und melden, sobald der Abstand größer wird. Der Unterschied im Detail.
Beim nächsten Mal früher merken
Bei einer Instanz kannst du diese Prüfung selbst laufen lassen – es gibt einen kostenlose Workflow der die n8n-API liest und aktive Workflows auflistet, die still geworden sind. Er hat einen ehrlichen Makel: Er lebt in der Instanz, die er überwacht – ein Neustart, der deine Trigger stehen lässt, kann also auch die Prüfung stehen lassen.
Über mehrere Kundeninstanzen hinweg ist dieser Makel nicht mehr hinnehmbar, und die Prüfung muss von außen laufen. Genau das macht Duskwatch – es leitet das erwartete Intervall aus dem Zeitplan jedes Workflows ab, du stellst also keine Schwelle je Workflow ein.
Duskwatch beobachtet die n8n-Instanzen, die du für Kunden betreibst, von außen und meldet die Ausfälle, die keinen Fehler erzeugen: den Lauf, den es nie gab, und die Instanz, die nicht mehr antwortet.