Wenn ein Workflow nachts scheitert. Fehlerbehandlung in n8n
Von Henrik Horn · · 4 Minuten
Jeder Workflow scheitert irgendwann
Eine Schnittstelle antwortet nicht, ein Zugang läuft ab, jemand benennt ein Feld im CRM um. Die Frage ist nicht ob, sondern wer es merkt.
Im Test läuft jeder Workflow. Im Betrieb trifft er auf echte Daten, auf Wartungsfenster und auf Menschen, die Dinge ändern, ohne Bescheid zu sagen. Ein Workflow ohne Fehlerbehandlung bricht dann still ab. Im besten Fall fällt es nach ein paar Stunden auf. Im schlechtesten nach Wochen, wenn ein Kunde fragt, wo seine Rechnung bleibt.
n8n bringt alles mit, was es für einen ruhigen Betrieb braucht. Man muss es nur einschalten. Wir denken dabei in drei Ebenen.
Die drei Ebenen
Von der einzelnen Node bis zum Wächter über allen Workflows.
- 1
Auf der Node
Jede Node hat in ihren Einstellungen „Retry On Fail“. Damit versucht sie es bei einem Fehler noch einmal, mit einstellbarer Zahl an Versuchen und Wartezeit dazwischen. Das fängt die meisten kurzen Aussetzer einer Schnittstelle ab. Unter „On Error“ legen Sie fest, was danach passiert: anhalten, weitermachen, oder weitermachen über einen eigenen Fehlerausgang.
- 2
Im Workflow
Der Fehlerausgang ist für bekannte Fälle gedacht. Fehlt einem Datensatz ein Pflichtfeld, muss nicht der ganze Lauf scheitern. Der Datensatz wandert in eine Liste für Klärfälle, die übrigen laufen weiter.
- 3
Über dem Workflow
Für alles Unerwartete gibt es den Error Workflow. Ein eigener Workflow, der mit der Node „Error Trigger“ beginnt und in den Einstellungen jedes anderen Workflows als Fehlerbehandlung eingetragen wird. Scheitert ein Lauf, startet er und meldet sich.
Ein Error Workflow reicht für alle. Er bekommt den Namen des gescheiterten Workflows, die letzte ausgeführte Node, die Fehlermeldung und den Link zur Ausführung. Mehr braucht es nicht, um in einer Minute zu wissen, wo man suchen muss.
Wiederholen ist nicht immer harmlos
Ein zweiter Versuch beim Lesen schadet nie. Beim Schreiben kann er teuer werden.
Angenommen, ein Workflow legt eine Rechnung an. Die Schnittstelle nimmt den Auftrag an, antwortet aber zu spät, und n8n wertet das als Fehler. Mit „Retry On Fail“ wird die Rechnung ein zweites Mal angelegt. Technisch ist alles korrekt gelaufen, fachlich hat der Kunde jetzt zwei Rechnungen.
Deshalb schalten wir Wiederholungen bei schreibenden Schritten nur ein, wenn der Schritt idempotent ist. Zweimal ausgeführt ergibt er dann dasselbe wie einmal. Drei Wege dorthin:
- Vor dem Anlegen prüfen, ob es den Datensatz schon gibt
- Einen eindeutigen Schlüssel mitschicken, den das Zielsystem wiedererkennt
- Anlegen oder Aktualisieren in einem Schritt, wo das Zielsystem es anbietet
Was in eine gute Fehlermeldung gehört
Eine Meldung, die nur „Workflow failed“ sagt, weckt jemanden auf, ohne ihm zu helfen.
- Welcher Workflow, in klarer Sprache statt interner Kennung
- An welcher Stelle, also die Node, die gescheitert ist
- Die Fehlermeldung selbst, ungekürzt
- Welcher Datensatz betroffen ist, etwa Kunde oder Rechnungsnummer
- Der Link zur Ausführung in n8n
- Wer zuständig ist, falls die Meldung in einem Team-Kanal landet
Die Meldung geht dorthin, wo das Team ohnehin arbeitet, meist in einen eigenen Slack-Kanal. Eine E-Mail an ein Sammelpostfach liest nachts niemand.
Der Fehler, den n8n nicht meldet
Ein Workflow, der gar nicht erst startet, scheitert auch nicht. Also meldet er sich nie.
Ein zeitgesteuerter Workflow wird deaktiviert, eine Schnittstelle schickt keine Webhooks mehr, ein Zugang läuft aus, bevor der Trigger feuert. In all diesen Fällen gibt es keinen Fehler, nur Stille. Dagegen hilft ein Lebenszeichen. Jeder wichtige Workflow schreibt am Ende seinen letzten erfolgreichen Lauf weg, und ein kleiner Wächter schaut einmal am Tag, ob alle sich gemeldet haben.
Error Workflow eingetragen, Wiederholungen nur bei lesenden oder idempotenten Schritten, eine Liste für Klärfälle, Meldungen in einen eigenen Kanal und ein tägliches Lebenszeichen. Kein Workflow geht bei uns ohne diese fünf Punkte in Betrieb.
