Ein n8n-Fehlerworkflow kann mehrere Abläufe bedienen

Ein n8n-Fehlerworkflow kann für mehrere Hauptworkflows verwendet werden. Der separate Ablauf beginnt mit einem Error Trigger, wird gespeichert und anschließend in den Einstellungen des jeweiligen Hauptworkflows ausgewählt. Das beschreibt die Dokumentation zur Fehlerbehandlung (Stand 3. Oktober 2026).

Mit einem solchen Ablauf kann ein Team auf fehlgeschlagene Ausführungen reagieren, etwa durch eine Nachricht. Die Daten, die der Error Trigger erhält, sind jedoch nicht in jedem Fehlerfall gleich. Ein zentraler Fehlerweg muss diese Unterschiede berücksichtigen.

Beim Triggerfehler startet der Hauptworkflow nicht. Fehlende Ausführungsfelder müssen deshalb von einem erfolgreichen Ergebnis unterschieden werden.

Ein Fehler vor der Ausführung liefert weniger Kontext#

execution.id und execution.url setzen voraus, dass die Ausführung in der Datenbank gespeichert wurde. Bei einem Fehler im Trigger des Hauptworkflows fehlen diese Angaben, weil der Hauptworkflow nicht ausgeführt wird. In diesem Fall enthält der Fehlerkontext weniger Informationen unter execution und mehr unter trigger.

execution.retryOf ist dagegen nur vorhanden, wenn eine fehlgeschlagene Ausführung wiederholt wurde. Ein Protokoll darf dieses Feld daher nicht bei jedem Fehler voraussetzen.

Die Dokumentation nennt außerdem den Node Stop And Error, mit dem ein Workflow unter selbst festgelegten Bedingungen bewusst fehlschlagen kann. Der Fehlerworkflow erhält damit auch bewusst ausgelöste Fehler. Der Ausgangspunkt für eine zentrale Benachrichtigung ist der jeweilige Fehlerkontext: Er zeigt, ob der Hauptworkflow schon ausgeführt wurde und welche gespeicherten Ausführungsdaten verfügbar sind.