Fehlerbehandlung in n8n: Warum Workflows nachts still scheitern

Ein Workflow läuft seit Monaten. Dann ändert ein Anbieter ein Feld in seiner API, ein Token läuft ab oder ein Kunde trägt ein Datum im falschen Format ein. Der Workflow bricht ab – und niemand erfährt davon. Aufgefallen ist es erst, als die Buchhaltung nach fehlenden Rechnungen fragt oder ein Interessent sich beschwert, dass auf seine Anfrage nie jemand reagiert hat.

n8n bringt alle Werkzeuge mit, um das zu verhindern. Sie sind aber nicht automatisch aktiv. Ein frisch gebauter Workflow hat keine Wiederholung, keinen Fehlerausgang und keinen Alarm. Fehlgeschlagene Läufe erscheinen nur in der Liste der Ausführungen, und die sieht sich nachts um drei niemand an.

Die vier Ursachen für stille Fehler

1. Kein Error-Workflow hinterlegt. Der Lauf schlägt fehl, wird als „Error“ gespeichert, und das war es.
2. „Continue“ als Notlösung. Jemand hat bei einem störrischen Node „On Error: Continue“ eingestellt, damit der Workflow durchläuft. Ab jetzt läuft er auch durch, wenn wirklich etwas kaputt ist – nur mit leeren Daten.
3. Fachliche Fehler ohne technischen Fehler. Die API antwortet mit Status 200, aber im Body steht "success": false. Oder die Suche nach einem Kunden liefert null Treffer, und der Workflow legt fröhlich einen Datensatz ohne Kunde an. Für n8n ist das ein erfolgreicher Lauf.
4. Der Trigger feuert gar nicht. Ein Webhook wird nicht mehr aufgerufen, ein Polling-Trigger findet nichts, weil sich die Datenquelle geändert hat. Es gibt keinen fehlgeschlagenen Lauf, weil es gar keinen Lauf gibt.

Für jede dieser Ursachen gibt es ein eigenes Mittel. Wir gehen sie in der Reihenfolge durch, in der wir sie in einem Workflow einbauen.

Ebene 1: Vorübergehende Fehler wiederholen

Viele Fehler verschwinden von selbst: ein Timeout, ein kurzzeitig überlasteter Server, ein „429 Too Many Requests“. Dafür gibt es in den Einstellungen jedes Nodes die Option Retry On Fail mit Max. Tries und Wait Between Tries (ms).

Darauf achten wir:

• Wiederholung nur an Nodes, die externe Dienste aufrufen (HTTP Request, CRM, Buchhaltung, Mail, KI-Modelle). Einen Code-Node mit einem Logikfehler zu wiederholen bringt nichts.
• Drei bis fünf Versuche mit einigen Sekunden Abstand reichen für kurze Störungen. Für längere Ausfälle ist die Wiederholung im Node das falsche Mittel – dafür siehe Ebene 4.
• Wiederholung nur bei Aufrufen, die sich gefahrlos wiederholen lassen. Ein „Rechnung anlegen“, das in einen Timeout läuft, kann auf der Gegenseite trotzdem erfolgreich gewesen sein. Vor einer zweiten Anlage muss geprüft werden, ob es den Datensatz schon gibt.

Wichtig: Wird an demselben Node zusätzlich eine der „Continue“-Optionen unter On Error gesetzt, verhält sich die Wiederholung je nach Version anders als erwartet. Testen Sie die Kombination bewusst, statt sich auf die Annahme zu verlassen.

Ebene 2: Erwartbare Fehler im Workflow selbst behandeln

Unter Settings → On Error hat jeder Node drei Möglichkeiten:

Option	Verhalten	Wann sinnvoll
Stop Workflow	Lauf bricht ab, gilt als fehlgeschlagen	Standard; richtig, wenn ein Fehler den ganzen Lauf wertlos macht
Continue	Lauf geht weiter, die Fehlerdaten werden weitergereicht	fast nie; verdeckt Fehler
Continue (using error output)	der Node bekommt einen zweiten Ausgang für Fehler	wenn der Fehler eine bekannte, behandelbare Situation ist

Der Fehlerausgang ist das Werkzeug für fachlich erwartbare Fälle. Beispiel: Ein Kontakt soll im CRM aktualisiert werden, existiert dort aber nicht. Statt abzubrechen, führt der Fehlerausgang zu einem Zweig, der den Kontakt anlegt. Oder eine Zeile mit ungültigen Daten wird in einer Tabelle „zur Prüfung“ abgelegt, während die übrigen Zeilen normal weiterlaufen.

Die Regel dabei: Jeder Fehlerausgang endet irgendwo, wo ein Mensch es sieht. Ein Fehlerausgang, der ins Leere läuft, ist nur eine aufwendigere Form von „Continue“.

Ebene 3: Fachliche Fehler zu echten Fehlern machen

Für Ursache 3 – die API sagt „200 OK“, aber das Ergebnis ist unbrauchbar – gibt es den Node Stop And Error. Er beendet den Lauf absichtlich mit einer eigenen Fehlermeldung. Davor steht ein IF-Node, der prüft, ob das Ergebnis plausibel ist:

• Hat die Kundensuche genau einen Treffer geliefert?
• Ist die Rechnungssumme größer als null?
• Enthält die Antwort die erwartete ID?

HTTP Request ──► IF (Antwort enthält id?) ──ja──► weiter
                          │
                          └─nein──► Stop And Error
                                    "Lexware: keine Rechnungs-ID für Bestellung {{ $json.order }}"

Eine gute Fehlermeldung enthält, welcher Datensatz betroffen ist. „Fehler im Workflow“ hilft am nächsten Morgen niemandem; „Keine Rechnung für Bestellung #1042, Lexware antwortet: Ländercode fehlt“ dagegen schon.

Ebene 4: Ein zentraler Error-Workflow

Alles, was trotz der ersten drei Ebenen scheitert, muss gemeldet werden. Dafür legen Sie einen eigenen Workflow an, der mit dem Error Trigger beginnt, und hinterlegen ihn in jedem produktiven Workflow unter Workflow Settings → Error Workflow.

Der Error Trigger liefert unter anderem den Namen des Workflows, die ID der Ausführung, eine URL zur Ausführung, den zuletzt ausgeführten Node und die Fehlermeldung. Daraus baut der Error-Workflow eine Nachricht, zum Beispiel per E-Mail oder in einen Slack-Kanal:

Workflow:  Shopify → Lexware Rechnung
Node:      Rechnung anlegen
Fehler:    401 Unauthorized
Lauf:      https://n8n.example.de/workflow/…/executions/…

Worauf wir beim Error-Workflow achten:

• Ein Error-Workflow für alle reicht meistens. Ausnahmen sind Abläufe, deren Fehler an andere Personen gehen sollen.
• Der Error-Workflow muss selbst nicht aktiviert sein, er wird vom fehlgeschlagenen Workflow aufgerufen.
• Er wird bei manuellen Testläufen im Editor nicht ausgelöst. Wer die Alarmierung testen will, muss den Workflow produktiv laufen lassen und einen Fehler provozieren – etwa mit einem temporären Stop And Error.
• Halten Sie den Error-Workflow so einfach wie möglich. Wenn er selbst von einer API abhängt, die gerade ausgefallen ist, erfahren Sie wieder nichts. Eine schlichte E-Mail über SMTP ist oft die robusteste Wahl.

Ebene 5: Merken, wenn gar nichts passiert

Gegen Ursache 4 – der Workflow läuft überhaupt nicht mehr – hilft keine Fehlerbehandlung, denn es gibt keinen Fehler. Hier braucht es eine Gegenprobe von außen:

• Heartbeat: Der Workflow meldet bei jedem erfolgreichen Lauf an einen Überwachungsdienst. Bleibt die Meldung länger als erwartet aus, gibt es Alarm. Das passt für regelmäßige Abläufe wie einen nächtlichen Abgleich.
• Plausibilitäts-Workflow: Ein zweiter Workflow prüft einmal am Tag, ob es zu jeder bezahlten Bestellung von gestern eine Rechnung gibt. Klingt doppelt, findet aber genau die Fälle, die sonst niemand findet.
• Webhook-Status beim Absender: Viele Systeme (Shopify, Stripe, HubSpot) zeigen fehlgeschlagene Webhook-Zustellungen an. Manche deaktivieren einen Webhook nach wiederholten Fehlschlägen sogar. Ein Blick dort gehört zur Fehlersuche.

Ausführungsdaten richtig aufbewahren

Damit Sie einen Fehler nachvollziehen können, müssen fehlgeschlagene Ausführungen gespeichert werden. In den Workflow-Einstellungen lässt sich festlegen, ob erfolgreiche und fehlgeschlagene Läufe gespeichert werden. Bei selbst gehostetem n8n kommt die automatische Bereinigung über Umgebungsvariablen dazu:

EXECUTIONS_DATA_PRUNE=true
EXECUTIONS_DATA_MAX_AGE=336   # Stunden, hier 14 Tage

Fehlgeschlagene Läufe speichern, erfolgreiche bei hohem Volumen eher nicht – und die Aufbewahrung nicht länger als nötig, denn in den Ausführungsdaten stehen Namen, Adressen und E-Mail-Inhalte.

Checkliste für jeden produktiven Workflow

• Error Workflow in den Workflow-Einstellungen hinterlegt
• Retry On Fail an allen Nodes mit externen Aufrufen
• Kein Node steht ohne Grund auf „Continue“
• Jeder Fehlerausgang endet in einer Meldung oder einer Prüfliste
• Plausibilitätsprüfungen mit Stop And Error, wo die API „Erfolg“ meldet, ohne Erfolg zu haben
• Fehlermeldungen nennen den betroffenen Datensatz
• Alarm an eine benannte Person, nicht an ein ungelesenes Postfach
• Gegenprobe für Abläufe, deren Ausbleiben niemand bemerken würde
• Alarmierung einmal echt getestet

Wie wir das handhaben

Bei jedem Workflow, den wir liefern, gehört die Fehlerbehandlung zum Lieferumfang. Wiederholungen, eine Meldung per E-Mail oder Slack an die Person, die Sie benennen, und Zugangsdaten im Credentials-Speicher Ihrer Instanz sind feste Abnahmekriterien. Den Workflow liefern wir deaktiviert, aktiviert wird er erst nach Ihrer Abnahme.

Häufige Fragen

Warum bekomme ich keine Meldung, wenn ein n8n-Workflow fehlschlägt?

Weil n8n ohne hinterlegten Error-Workflow keine Meldung verschickt. Der fehlgeschlagene Lauf wird nur in der Liste der Ausführungen gespeichert. Abhilfe schafft ein eigener Workflow mit dem Error Trigger, der unter Workflow Settings → Error Workflow in jedem produktiven Workflow eingetragen wird.

Wann ist „Continue“ bei On Error sinnvoll?

Fast nie, denn der Workflow läuft dann auch mit leeren oder fehlerhaften Daten weiter und verdeckt den Fehler. Für erwartbare Fälle ist „Continue (using error output)“ die bessere Wahl: Der Node erhält einen eigenen Fehlerausgang, der zu einem behandelnden Zweig führt. Wichtig ist, dass jeder Fehlerausgang dort endet, wo ein Mensch ihn sieht.

Wie merke ich, dass ein Workflow gar nicht mehr läuft?

Nur durch eine Gegenprobe von außen, denn ohne Lauf gibt es auch keinen Fehler. Bewährt haben sich ein Heartbeat an einen Überwachungsdienst, ein täglicher Plausibilitäts-Workflow, der etwa prüft, ob es zu jeder bezahlten Bestellung eine Rechnung gibt, und ein Blick auf den Webhook-Status beim Absender. Welche Variante passt, hängt davon ab, wie regelmäßig der Ablauf läuft.

---

Laufen bei Ihnen Workflows ohne diese Absicherung, ist das Nachrüsten eine gut abgegrenzte Aufgabe im Prozess-Abo. Sie legen sie als Karte auf Ihr Board, und die Checkliste oben wird zu den Abnahmekriterien. Wie viele Workflows auf eine Karte passen, klären wir, bevor wir starten. Zugang geben Sie per Einladung in Ihre n8n-Instanz, nie per Passwort oder API-Schlüssel. Wir liefern jede Aufgabe 48 Stunden nach Start (gezählt Mo 8 – Fr 16 Uhr) als deaktivierte Kopie, die Sie nach der Abnahme aktivieren. Jede Lieferung prüft und gibt ein Senior-Entwickler frei. Die Meldungen gehen danach an die Person, die Sie benennen. Ändert sich später eine Schnittstelle, legen Sie die Anpassung als neue Karte an. Die erste Aufgabe erledigen wir kostenlos, eine pro Unternehmen. Typische Automatisierungsaufgaben finden Sie im Leistungskatalog.