Error Handling in n8n: Error Workflows und Fehler-Benachrichtigungen

Ein Error Workflow ist in n8n eine ganz normale Automatisierung, die Sie in den Workflow-Einstellungen unter „Error workflow" hinterlegen und die automatisch startet, sobald die Ausführung eines anderen Workflows fehlschlägt. Kombiniert mit dem Error Trigger Node, den Retry-On-Fail-Einstellungen einzelner Nodes und einer Benachrichtigung per E-Mail oder Microsoft Teams lässt sich so sicherstellen, dass Fehler nicht stillschweigend untergehen, sondern automatisch wiederholt oder an das zuständige Team gemeldet werden. Stand: Juli 2026.

Was ist ein Error Workflow und wann greift er?

Ein Error Workflow ist laut n8n-Dokumentation ein separater Workflow, den Sie „in Workflow Settings" für eine andere Automatisierung hinterlegen und der ausgeführt wird, sobald deren Ausführung fehlschlägt. Typischer Anwendungsfall ist laut Dokumentation, bei einem Fehler „E-Mail- oder Slack-Benachrichtigungen" zu verschicken. Ein einzelner Error Workflow lässt sich dabei für mehrere produktive Workflows wiederverwenden, sodass Sie nicht für jede Automatisierung eine eigene Fehlerbehandlung aufbauen müssen. Wichtig ist, dass ein Error Workflow sich nicht durch manuelles Ausführen testen lässt: Der Error Trigger reagiert laut Dokumentation ausschließlich, wenn eine automatisierte Ausführung eines anderen Workflows tatsächlich scheitert. Weitere Details dazu finden Sie in der n8n-Dokumentation zur Fehlerbehandlung.

Wie richten Sie einen Error Workflow ein?

Sie legen zunächst einen eigenständigen Workflow an, der ausschließlich für den Fehlerfall existiert, und verknüpfen ihn danach mit dem zu überwachenden Workflow.

• Error-Handler-Workflow anlegen: Erstellen Sie einen neuen Workflow mit dem Error Trigger als erster Node, geben Sie ihm einen Namen wie „Error Handler" und speichern Sie ihn.
• Zielworkflow öffnen: Öffnen Sie den Workflow, dessen Fehler Sie überwachen möchten, und gehen Sie dort auf Options und anschließend Settings.
• Error Workflow zuweisen: Wählen Sie im Feld „Error workflow" den zuvor erstellten Error-Handler-Workflow aus und speichern Sie die Einstellung.

Ein Workflow, der nur über den Error Trigger gestartet wird, muss dabei nicht separat veröffentlicht werden, damit er als Error Workflow funktioniert.

Welche Informationen liefert der Error Trigger bei einem Fehler?

Der Error Trigger übergibt strukturierte Daten zur fehlgeschlagenen Ausführung, aus denen sich eine aussagekräftige Benachrichtigung zusammensetzen lässt. Laut der Dokumentation zum Error Trigger Node enthalten diese Daten unter anderem:

• execution.id und execution.url: Kennung und Link zur fehlgeschlagenen Ausführung, fehlen jedoch, wenn der Fehler bereits im auslösenden Trigger-Node der Hauptautomatisierung liegt.
• execution.error: die eigentliche Fehlermeldung inklusive Stack Trace.
• execution.lastNodeExecuted: die Node, an der die Ausführung gescheitert ist.
• execution.retryOf: nur vorhanden, wenn die fehlgeschlagene Ausführung selbst bereits eine Wiederholung war.
• workflow.id und workflow.name: welcher Workflow betroffen ist.

Zusätzlich lässt sich mit der Stop-And-Error-Node gezielt ein Fehler erzwingen, um etwa bei einer unplausiblen Datenlage bewusst den Error Workflow auszulösen, auch wenn technisch kein Node-Fehler vorliegt.

Wie lässt sich ein fehlgeschlagener Aufruf automatisch per Retry wiederholen?

Bevor eine Ausführung überhaupt als endgültig fehlgeschlagen gilt und im Error Workflow landet, lässt sich jede einzelne Node so konfigurieren, dass sie einen gescheiterten Aufruf zunächst automatisch mehrfach wiederholt. Dazu öffnen Sie die betreffende Node, wechseln zu den Einstellungen und aktivieren dort „Retry On Fail". Über „Max Tries" legen Sie fest, wie oft n8n den Versuch wiederholt, über „Wait Between Tries (ms)" die Wartezeit zwischen den Versuchen in Millisekunden. Beide Werte sind laut Dokumentation zum Umgang mit API-Rate-Limits begrenzt: Max Tries auf maximal 5, Wait Between Tries auf maximal 5000 Millisekunden. Gerade bei Diensten mit Rate Limits empfiehlt die Dokumentation, die Wartezeit über dem Rate-Limit-Intervall der jeweiligen API anzusetzen, damit der nächste Versuch nicht erneut abgewiesen wird.

Wie benachrichtigen Sie Ihr Team per Mail oder Microsoft Teams?

Nach dem Error Trigger fügen Sie im Error Workflow einfach die Node hinzu, über die die Benachrichtigung verschickt werden soll. Für E-Mail-Benachrichtigungen eignet sich die Send-Email-Node, die eine SMTP-Zugangsdaten-Verbindung benötigt und Nachrichten wahlweise als Text, HTML oder in beiden Formaten verschickt. Für die Meldung in einem Teams-Kanal steht die Microsoft-Teams-Node zur Verfügung, die über hinterlegte Microsoft-Zugangsdaten Nachrichten in einen Kanal postet. In beiden Fällen bauen Sie den Nachrichtentext aus den vom Error Trigger gelieferten Feldern zusammen, etwa dem Workflow-Namen, der Fehlermeldung aus execution.error und dem Link zur Ausführung über execution.url, damit die Empfänger sofort erkennen, welcher Prozess betroffen ist und wo sie die Details nachvollziehen können. Wer eine bestehende n8n-Umgebung technisch fundiert mit Error Workflows, Retry-Strategien und Benachrichtigungen absichern lassen möchte, findet dazu Unterstützung bei den n8n-Leistungen von NordFlux.

Häufige Fragen zu Error Handling in n8n

Brauche ich für jeden Workflow einen eigenen Error Workflow?

Nein, ein einzelner Error Workflow lässt sich in den Settings mehrerer Workflows als gemeinsamer Error Workflow hinterlegen. So reicht oft eine zentrale Benachrichtigungs-Automatisierung für viele produktive Workflows aus. Für besonders kritische Prozesse können Sie trotzdem einen spezialisierten Error Workflow mit eigener Eskalationslogik anlegen.

Kann ich einen Error Workflow manuell testen?

Nein, laut n8n-Dokumentation lässt sich ein Error Workflow nicht durch manuelles Ausführen testen, da der Error Trigger nur reagiert, wenn eine automatisierte Ausführung eines anderen Workflows tatsächlich fehlschlägt. Um das Verhalten dennoch zu prüfen, können Sie in einem Testworkflow mit der Stop-And-Error-Node gezielt einen Fehler erzwingen und so den verknüpften Error Workflow auslösen.

Was ist der Unterschied zwischen Retry On Fail und einem Error Workflow?

Retry On Fail wiederholt den Aufruf einer einzelnen Node innerhalb derselben Ausführung automatisch, während der Error Workflow erst greift, wenn die gesamte Ausführung trotz aller Wiederholungsversuche endgültig fehlgeschlagen ist. Beide Mechanismen ergänzen sich sinnvoll: Retries fangen kurzfristige Störungen wie überschrittene Rate Limits ab, der Error Workflow informiert anschließend Menschen über endgültige Ausfälle.

Muss der Error-Handler-Workflow aktiviert oder veröffentlicht sein?

Nein, ein Workflow, der ausschließlich über den Error Trigger gestartet wird, muss laut Dokumentation nicht gesondert veröffentlicht werden, um zu funktionieren. Er wird automatisch aufgerufen, sobald ein anderer Workflow ihn in seinen Einstellungen als Error Workflow referenziert und selbst fehlschlägt.