Error-Handling in n8n: Workflows robust gegen Ausfälle machen

Ein Workflow, der einwandfrei läuft – bis er es eines Tages nicht mehr tut. Die Zahlungs-API antwortet nicht, das CRM meldet einen Timeout, ein Feld im JSON heißt plötzlich anders als erwartet. Wenn in diesem Moment kein Error-Handling greift, bricht der Workflow ab, ohne dass jemand davon erfährt. Genau das ist im Geschäftsalltag riskant: eine nicht erfasste Bestellung, eine fehlende Rechnung, ein Lead, der nie im CRM landet.

In diesem Artikel zeigen wir, wie du mit gezieltem Error-Handling n8n-Workflows so aufbaust, dass sie Fehler erkennen, sinnvoll reagieren und dich zuverlässig informieren – statt einfach nur stillzustehen. Eine durchdachte Fehlerbehandlung ist dabei kein Nice-to-have, sondern die Grundlage für zuverlässige Automatisierung im Produktivbetrieb.

Warum Workflows überhaupt scheitern

Bevor man Fehler behandelt, lohnt sich ein Blick darauf, welche Fehlerarten in automatisierten Prozessen typischerweise auftreten:

• Transiente Fehler: Ein kurzer Netzwerkaussetzer, ein API-Server, der gerade neu startet, ein HTTP-503-Status. Diese Fehler verschwinden oft von selbst, wenn man es kurz danach erneut versucht.
• Ungültige oder unerwartete Daten: Ein Webhook liefert ein leeres Feld, eine API gibt null statt eines Strings zurück, ein Formular wird unvollständig abgeschickt.
• Schema-Änderungen: Ein verbundener Dienst ändert ein Feld (z. B. wird user.name zu user.fullName), ohne dass du es mitbekommst.
• Berechtigungs- und Auth-Fehler: Ein API-Key ist abgelaufen, ein OAuth-Token muss erneuert werden.

Jede dieser Kategorien verlangt eine andere Reaktion – ein Timeout lässt sich oft automatisch wiederholen, ein Berechtigungsfehler braucht dagegen menschliches Eingreifen.

Kurzer Kontext: Wie n8n Workflows ausführt

n8n verbindet Systeme über sogenannte Nodes – einzelne Bausteine für Aktionen wie „HTTP-Request senden", „Datensatz in Airtable schreiben" oder „Slack-Nachricht posten". Ein Trigger-Node startet den Workflow, etwa durch einen Webhook (einen eingehenden HTTP-Aufruf), einen Zeitplan oder ein Ereignis in einem angebundenen System. Läuft ein Node auf einen Fehler, entscheidet die Konfiguration des Workflows, was als Nächstes passiert.

Die drei Ebenen der Fehlerbehandlung in n8n

1. Node-Ebene: Retry on Fail und Continue on Fail

Auf jedem Node lässt sich unter den Node-Einstellungen festlegen, wie n8n bei einem Fehler reagieren soll:

1. Retry On Fail aktivieren: n8n wiederholt die Ausführung des Nodes automatisch eine festgelegte Anzahl Mal, mit einer einstellbaren Wartezeit dazwischen. Das ist die richtige Wahl für transiente Fehler, etwa bei einer kurzzeitig überlasteten API.
2. On Error konfigurieren: Du legst fest, ob der Workflow bei einem Fehler abbrechen, mit dem nächsten Node weiterlaufen oder über einen eigenen Fehler-Ausgang verzweigen soll. So kannst du beispielsweise einen fehlgeschlagenen CRM-Eintrag protokollieren, ohne dass der gesamte Workflow stoppt.

Für einfache, klar abgrenzbare Fehlerquellen – etwa einen einzelnen API-Call, der gelegentlich einen Timeout wirft – reicht diese Node-Konfiguration meist vollkommen aus.

2. Workflow-Ebene: Der Error Trigger und der Error Workflow

Für Fehler, die trotz Retry nicht behoben werden, bietet n8n eine zweite Sicherheitsebene: den Error Trigger-Node. Dieser startet einen separaten, eigenen Workflow – den sogenannten Error Workflow – sobald ein anderer Workflow fehlschlägt.

So richtest du das ein:

1. Lege einen neuen Workflow an, der ausschließlich als Fehlerbehandlung dient.
2. Füge als ersten Node den Error Trigger ein. Er liefert dir Informationen zum fehlgeschlagenen Workflow: Name, Execution-ID, den Fehlertext und den Node, an dem es scheiterte.
3. Baue darauf eine Benachrichtigung, etwa eine Slack- oder E-Mail-Nachricht an das zuständige Team, inklusive Link zur fehlgeschlagenen Ausführung.
4. Öffne den ursprünglichen (fehleranfälligen) Workflow, gehe in die Workflow-Einstellungen und wähle unter „Error Workflow" den eben erstellten Fehler-Workflow aus.

Ab diesem Zeitpunkt löst jeder unbehandelte Fehler in diesem Workflow automatisch eine Benachrichtigung aus – der Kernbaustein für „keine stillen Fehler mehr".

3. Explizite Fehler auslösen: Der Stop-and-Error-Node

Nicht jeder Fehlerfall wird von einem Node selbst als Fehler erkannt. Wenn zum Beispiel eine API technisch erfolgreich antwortet, der Inhalt aber inhaltlich nicht stimmt (etwa ein leeres Ergebnis, wo Daten erwartet werden), läuft der Workflow formal ohne Fehler weiter. Mit dem Stop-and-Error-Node kannst du in solchen Fällen selbst einen Fehler auslösen, inklusive eigener Fehlermeldung. Das ist besonders nützlich in Kombination mit einem IF- oder Switch-Node, der die Datenqualität vorher prüft.

Praktisches Beispiel: Robuste Rechnungsverarbeitung

Nehmen wir einen Workflow, der eingehende Rechnungs-E-Mails verarbeitet, Daten per OCR-Dienst extrahiert und die Rechnung ins Buchhaltungssystem überträgt. Eine robuste Variante könnte so aussehen:

1. Trigger: IMAP-E-Mail-Trigger erkennt neue Rechnungs-Mail.
2. Extraktion: HTTP-Request-Node ruft einen externen OCR-Dienst auf – mit Retry On Fail (z. B. 3 Versuche, 5 Sekunden Abstand), da OCR-APIs gelegentlich unter Last kurz nicht antworten.
3. Validierung: IF-Node prüft, ob Rechnungsbetrag und Lieferantenname erfolgreich extrahiert wurden. Falls nicht, löst ein Stop-and-Error-Node einen Fehler mit klarer Beschreibung aus.
4. Übertragung: Node zur Buchhaltungssoftware, ebenfalls mit definiertem „On Error"-Verhalten, damit ein einzelner fehlerhafter Datensatz nicht die gesamte Stapelverarbeitung blockiert.
5. Fehler-Workflow: Bei jedem unbehandelten Fehler informiert eine Slack-Nachricht das Buchhaltungsteam samt Link zur betroffenen Ausführung, damit die Rechnung manuell nachbearbeitet werden kann.

So bleibt der Workflow bei kleinen, temporären Störungen automatisch stabil und meldet sich nur dann, wenn tatsächlich jemand eingreifen muss.

Typische Stolperfallen

• Retry ohne Begrenzung: Zu viele Wiederholversuche bei einem dauerhaft ausgefallenen Dienst erzeugen unnötige Last und verzögern die Fehlermeldung. Eine sinnvolle Obergrenze (meist 2–5 Versuche) reicht in der Praxis aus.
• Ein globaler Error Workflow für alle Workflows ungeprüft übernehmen: Nicht jeder Fehler hat die gleiche Dringlichkeit. Ein fehlgeschlagener interner Report ist unkritischer als ein nicht verarbeiteter Zahlungseingang – differenzierte Benachrichtigungswege (z. B. nach Priorität oder Team) sind oft sinnvoller als eine einzige Sammel-Slack-Nachricht.
• Fehlerbehandlung erst nachträglich einbauen: Wird Error-Handling erst ergänzt, wenn ein Ausfall bereits Schaden angerichtet hat, fehlt oft der Überblick, an welchen Stellen im Workflow es überhaupt kritisch werden kann. Es lohnt sich, Fehlerquellen schon beim Workflow-Design zu identifizieren.
• Fehlermeldungen ohne Kontext: Eine Slack-Nachricht wie „Workflow fehlgeschlagen" hilft niemandem. Execution-ID, betroffener Node und – wenn möglich – die betroffenen Daten (z. B. welcher Kunde, welche Bestellung) machen die Meldung erst handlungsfähig.

Was du selbst umsetzen kannst – und wo es komplexer wird

Retry-Einstellungen auf einzelnen Nodes und ein einfacher Error-Trigger-Workflow mit Slack- oder E-Mail-Benachrichtigung lassen sich mit ein wenig n8n-Erfahrung gut in Eigenregie umsetzen. Die n8n-Dokumentation beschreibt die Einstellungen im Detail, und die Grundstruktur ist in wenigen Stunden aufgebaut.

Anspruchsvoller wird es, sobald mehrere Workflows unterschiedliche Fehlerprioritäten und Eskalationswege benötigen, wenn Fehler über mehrere Systeme hinweg korreliert werden müssen (z. B. „Ist das ein bekanntes, temporäres API-Problem oder ein neuer Fehler?") oder wenn Wiederholungslogik mit Geschäftsregeln kombiniert werden soll – etwa „bei Zahlungsfehlern sofort eskalieren, bei Reporting-Fehlern erst nach drei Fehlschlägen". An diesem Punkt steigen Wartungsaufwand und Fehleranfälligkeit spürbar, und eine saubere, dokumentierte Fehlerarchitektur zahlt sich langfristig aus. Hier lohnt sich häufig externe Unterstützung bei Konzeption und Aufbau, gerade wenn intern die Kapazität fehlt, das sauber durchzuplanen.

Kurzer Blick auf Alternativen

Auch Zapier und Make bieten Fehlerbehandlung – Zapier etwa über automatische Wiederholungen bei bestimmten Plänen und E-Mail-Benachrichtigungen bei Fehlern, Make über sogenannte Error-Handler-Routen direkt im Szenario. n8n unterscheidet sich vor allem durch die freie Programmierbarkeit: Da Error-Trigger und Error-Workflow ganz normale Workflows sind, lässt sich die Fehlerlogik beliebig erweitern, etwa um eigene Priorisierung, Datenbank-Logging oder komplexe Eskalationsketten. Welcher Ansatz passt, hängt von der gewünschten Kontrolle und den vorhandenen technischen Ressourcen ab.

Fazit: So startest du selbst

Beginne klein: Aktiviere bei den kritischsten Workflows zunächst Retry On Fail an den Nodes, die externe Dienste ansprechen. Baue anschließend einen einfachen Error-Workflow mit Error-Trigger-Node und einer Slack- oder E-Mail-Benachrichtigung auf und hinterlege ihn in den Workflow-Einstellungen. Damit ist die Grundlage für „keine stillen Fehler mehr" gelegt.

Wenn deine Automatisierungslandschaft wächst und Fehlerbehandlung, Eskalation und Monitoring über viele Workflows hinweg konsistent und wartbar bleiben sollen, unterstützen wir dich gerne beim Aufbau einer robusten Fehlerarchitektur. Buche ein unverbindliches Gespräch und wir schauen uns gemeinsam an, wo sich das für dich lohnt.

Häufig gestellte Fragen

1. Was ist der Unterschied zwischen Retry On Fail und dem Error Workflow? Retry On Fail ist eine Einstellung auf einzelnen Nodes und wiederholt nur diesen einen Schritt automatisch – sinnvoll bei kurzzeitigen, transienten Fehlern. Der Error Workflow greift dagegen erst, wenn ein Fehler trotz Wiederholung bestehen bleibt und der gesamte Workflow abbricht; er dient primär der Benachrichtigung und Nachverfolgung, nicht der automatischen Behebung.

2. Muss ich für jeden Workflow einen eigenen Error Workflow anlegen? Nein, ein Error Workflow lässt sich in den Workflow-Einstellungen mehreren Workflows zuweisen. Bei unterschiedlicher Priorität oder unterschiedlichen Zuständigkeiten (z. B. Buchhaltung vs. Support) kann es aber sinnvoll sein, mehrere spezialisierte Error Workflows mit passenden Benachrichtigungswegen anzulegen.

3. Kann ich in n8n auch nur bestimmte Fehler abfangen, andere aber bewusst durchlaufen lassen? Ja. Über die „On Error"-Einstellung am jeweiligen Node lässt sich festlegen, ob der Workflow abbricht, weiterläuft oder über einen eigenen Fehler-Ausgang verzweigt. In Kombination mit einem IF-Node lässt sich so gezielt zwischen unkritischen und kritischen Fehlern unterscheiden.

4. Werden fehlgeschlagene Ausführungen in n8n gespeichert? n8n protokolliert Ausführungen inklusive Fehlerdetails im Execution-Log; wie lange diese gespeichert bleiben, hängt von den in den Einstellungen konfigurierten Aufbewahrungsregeln ab. Details dazu findest du in der offiziellen n8n-Dokumentation, da sich die Standardwerte je nach Version und Hosting-Variante unterscheiden können.

5. Lohnt sich Error-Handling auch bei kleinen, einfachen Workflows? Ja, zumindest in Grundform. Selbst ein einzelner Workflow, der beispielsweise Formulardaten ins CRM überträgt, sollte im Fehlerfall benachrichtigen statt schweigend zu scheitern – der Aufwand für einen einfachen Error-Trigger-Workflow ist gering, der Nutzen bei einem tatsächlichen Ausfall aber hoch.