Begriff
Error Workflow (n8n)
Warum wichtig?
Dieser Begriff ist ein Knoten im SengakujiWorks-Wissensnetz. Nutze Level 0 für die erste Einordnung, Level 1 für Praxis, Level 2 für technische Struktur und Level 3 für Grenzen, Fallstricke und Expertenkontext.
Der Error Workflow ist der Airbag für deine Automatisierung. In der perfekten Welt funktionieren APIs immer. In der echten Welt sind sie oft kaputt. Was passiert, wenn dein Haupt-Workflow gegen eine Wand fährt (API-Timeout, Datenbank voll)? Ohne Airbag: Der Workflow stürzt ab. Niemand merkt es. Der Kunde wartet ewig. Mit Airbag: Der Haupt-Workflow stürzt ab, aber der Error Workflow springt sofort an. Er fängt den Unfall ab und tut etwas Nützliches:
- Schickt dir eine Nachricht in Slack: "Achtung, Unfall bei Kunde Müller!"
- Schreibt den Fehler in eine Google Tabelle.
Merksatz: Ein separater Rettungsschirm-Workflow, der nur dann startet, wenn ein anderer Workflow scheitert.
Du brauchst zwei Workflows:
- Den Haupt-Workflow: Gehe in die "Workflow Settings" (Zahnrad) -> "Error Workflow". Wähle dort deinen Rettungs-Workflow aus.
- Den Error-Workflow:
Er startet nicht mit einem normalen Trigger, sondern mit dem Error Trigger.
Dieser Trigger liefert dir alle Details zum Unfall:
executionId: Wo ist es passiert?Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst zwei Workflows: 1. Den Haupt-Workflow: Gehe in die "Workflow Settings" (Zahnrad) - "Error Workflow". Wähle dort deinen Rettungs-Workflow aus. 2. Den Error-Workflow: Er startet nicht mit einem normalen Trigger, sondern mit dem Error Trigger. Dieser Trigger liefert dir alle Details zum Unfall: executionId: Wo ist es passiert? error: Was genau ist kaputt? ("404 Not Found"). workflow: Welcher Workflow war es?error: Was genau ist kaputt? ("404 Not Found").workflow: Welcher Workflow war es?Musterantwort: Beginne mit dem konkreten Fall, prüfe die Fakten und erkläre den Begriff daran. Für diesen Abschnitt gilt: Du brauchst zwei Workflows: 1. Den Haupt-Workflow: Gehe in die "Workflow Settings" (Zahnrad) - "Error Workflow". Wähle dort deinen Rettungs-Workflow aus. 2. Den Error-Workflow: Er startet nicht mit einem normalen Trigger, sondern mit dem Error Trigger. Dieser Trigger liefert dir alle Details zum Unfall: executionId: Wo ist es passiert? error: Was genau ist kaputt? ("404 Not Found"). workflow: Welcher Workflow war es?
Best Practice
Baue einen zentralen Error Workflow für alle deine Automatisierungen. Er sollte:
- Den Fehler nett formatieren.
- Ihn in einen Slack/Teams-Channel posten ("🚨 Alert").
- Vielleicht eine E-Mail an den Admin senden.
1. Continue On Fail vs. Error Workflow
An jedem Node gibt es die Setting "On Error: Continue". Was ist der Unterschied?
- Continue On Fail: Der Node ignoriert den Fehler. Der Workflow humpelt weiter. (Gut für "Nicht so wichtig").
- Error Workflow: Der Workflow stirbt sofort. Der Retter übernimmt. (Gut für "Katastrophe!").
2. Fehlertoleranz (Retry Strategy)
Manchmal willst du gar keinen Alarm, sondern einfach nur einen zweiten Versuch. Im HTTP Request Node gibt es "Retry on Fail". "Versuche es 3x, warte dazwischen 5 Sekunden." Erst wenn alle 3 Versuche scheitern, feuert der Error Workflow. Das löst 90% aller "API spinnt gerade"-Probleme von selbst.
3. Debugging mit Execution ID
Der Error Trigger liefert dir die executionId des abgestürzten Workflows.
Du kannst im Error Workflow einen Link generieren:
https://n8n.deine-firma.de/workflow/123/executions/{{ $json.executionId }}.
Wenn du den Alert in Slack bekommst, klickst du einfach auf den Link und landest direkt im Tatort. Genial!
1. Circuit Breaker Pattern Emulation
Wenn ein SaaS Endpoint (z.B. HubSpot) auf einem 503 Internal Server Error down geht, ist es absolut tödlich, wenn dein normaler Workflow 1000 Events aus der Queue abgreift, 1000 mal fehlschlägt und somit deine API-Retry-Budgets ratz-fatz pulverisiert (Thundering Herd Problem).
Der zentrale Error-Workflow kann ein architektonisches "Circuit Breaker Pattern" injizieren. Bei einem Crash schreibt der Error Workflow in einen persistenten Redis Store: {"hubspot_broken": true, "timestamp": 1234} (Trip the Circuit).
Der Haupt-Trigger-Node (oder ein Router) ist intelligent umgebaut und liest das Redis-Flag. Für die nächsten 5 Minuten werden alle neuen Events direkt in eine "Dead Letter Queue" verschoben oder sofort im Code verworfen, ohne die HubSpot API auch nur anzufassen (Fail Fast). Das schützt das System vor Load-Gemetzeln und erholt blockierte API Rate-Limits automatisch in der Wartezeit (Cool Down Period).
2. Execution Recovery Payload Analysis
Was einen Error-Workflow zur absoluten Data-Loss Versicherung macht, ist der tiefgreifende Zugriff auf the Execution-Datascopes des gescheiterten Runs.
Der Error Trigger liefert via $json.execution.error nicht nur Stacktraces, sondern den kompletten Knoten-Vektor (lastNodeExecuted).
Wenn ein Woocommerce Kauf durch einen Database Disconnect auf halbem Weg stirbt, extrahiert der Enterprise Error Workflow exakt die "abandoned JSON Items" aus dem Trigger-Log des Subsystems, paketiert sie in base64 und publiziert das Payload hart ins Kafka / S3 Recovery-Bucket. Ein Re-Run-Mechanismus im Monitoring Framework kann die Datensätze dann manuell punktgenau hinter dem gebrochenen Knoten ins System reihen, kein Datagrid wird in O(N)-Latenz verloren!
3. Isolation & Recursion Death Loops (Poison Pills)
Eine oft völlig übersehene Todesfalle beim Entwurf ist der endlose "Error Workflow Death Loop".
Was, falls der Error Workflow selbst einen Fehler im Versuch macht, einen Slack-Alert zu posten?
Wenn die On Error Setting des Master-Triggers falsch verlinkt ist (oder der Error-Workflow vererbt im Environment global an alle triggert), feuert der Error Workflow bei eigenem Fehler eine Sub-Execution Desselben Error-Workflows an. Dies spaltet sich exponentiell im Sekundentakt! Innerhalb von 30 Sekunden verpulvert der Server 10.000 Worker-Prozesse (Fork Bomb Logik), die Queue crasht die Postgres Database, Docker frisst 100% CPU.
Es ist gesetzliche Engineering-Pflicht, Error Trigger Nodes strukturell im Parameter-Flag zu kapseln ("Keine Error-Handler innerhalb der Error Chains evaluieren!") und die Slack-API Calls im Retter strikt unter statische Try-Catch Return-Blöcke Continue On Fail zu ketten, falls die Notifications API temporär verschwindet!
Quick-Check
Was ist der Unterschied zwischen einem Error Workflow und einem normalen Workflow?
Der Startpunkt. Ein Error Workflow startet durch den Error Trigger, wenn irgendwo anders etwas schiefgeht.Warum sollte man nicht für jeden Workflow einen eigenen Error Workflow bauen?
Wartungsaufwand. Es ist viel schlauer, einen zentralen "Global Error Handler" zu haben, den alle nutzen.Was passiert, wenn im Error Workflow selbst ein Fehler passiert?
Dann hast du ein Problem (Airbag zündet nicht). Dieser Fehler wird meistens nur ins Server-Log geschrieben. Halte den Error Workflow deshalb extrem simpel!