n8n Fehlerbehandlung & Monitoring: Workflows die nicht still scheitern
Ein still fehlgeschlagener Workflow ist gefährlicher als gar keine Automatisierung. Wie du n8n so absicherst, dass du von jedem Fehler sofort erfährst – mit Error-Workflow, Retry und Monitoring.
Das gefährlichste an einer Automatisierung ist nicht, dass sie fehlschlägt. Es ist, dass sie fehlschlägt und du es nicht merkst. Der Lead wird nicht ins CRM geschrieben, die Rechnung nicht verbucht, die Bestätigungs-Mail nicht verschickt – und weil „das ja automatisch läuft”, schaut niemand hin. Wochen später fällt auf, dass ein halbes Dutzend Anfragen im Nichts verschwunden ist. Schlechte Datenqualität kostet Unternehmen laut einer viel zitierten Gartner-Schätzung im Schnitt rund 12,9 Mio. $ pro Jahr – bei Selbstständigen geht es um kleinere Summen, aber dasselbe Prinzip: Ein stiller Fehler ist teurer als ein lauter. n8n gibt dir alle Werkzeuge, damit kein Fehler mehr unbemerkt bleibt. Du musst sie nur einschalten.
Das Wichtigste auf einen Blick
- Ein zentraler Error-Workflow kann für beliebig viele Workflows genutzt werden – einmal bauen, allen zuweisen
- Der Error-Trigger liefert Workflow-Name, Fehlermeldung und einen direkten Link zur fehlgeschlagenen Ausführung
- Retry On Fail wiederholt Nodes bei temporären Fehlern automatisch (aktuell bis 5 Versuche pro Node)
- On Error → Continue (using error output) fängt einzelne fehlerhafte Datensätze ab, statt den ganzen Lauf abzubrechen
- Self-hosted bekommst du Health-Checks (
/healthz) und Prometheus-Metriken (/metrics) für echtes Monitoring
Warum „läuft ja” die gefährlichste Annahme ist
Ein Workflow, der sichtbar mit einer roten Fehlermeldung abbricht, ist kein Problem – du siehst ihn und reparierst ihn. Das echte Risiko sind die Fehler, die niemand bemerkt: eine API antwortet kurz nicht, ein Feld ist leer, ein Rate-Limit greift. Der Workflow bricht ab, aber nichts schlägt Alarm.
Der Unterschied zwischen einem Hobby-Setup und einer produktiven Automatisierung ist genau das: Nicht ob Fehler passieren – die passieren immer –, sondern ob du sofort davon erfährst. Deshalb ist Fehlerbehandlung kein Nachgedanke, sondern Teil jedes Workflows, den du ernst meinst.
n8n bietet dafür drei Ebenen, die aufeinander aufbauen: den einzelnen Node (Retry, Fehler-Output), den gesamten Workflow (zentraler Error-Workflow) und die Instanz (Monitoring, Health-Checks). Gehen wir sie durch.
Ebene 1: Der zentrale Error-Workflow (das Wichtigste)
Das ist der Baustein, der aus „still scheitern” ein „sofort Bescheid wissen” macht. Die Idee: Ein einziger Workflow, der immer dann anspringt, wenn irgendein anderer Workflow fehlschlägt – und dich benachrichtigt.
Das Herzstück ist der Error-Trigger-Node. Er muss der erste Node im Fehler-Workflow sein und liefert bei jedem Fehler eine strukturierte Payload (n8n Docs):
| Feld | Inhalt |
|---|---|
workflow.name | Name des fehlgeschlagenen Workflows |
execution.error.message | Die konkrete Fehlermeldung |
execution.lastNodeExecuted | An welchem Node es gescheitert ist |
execution.url | Direkter Link zur fehlgeschlagenen Ausführung |
execution.mode | Wie er ausgelöst wurde (z. B. Trigger, manuell) |
Damit baust du in fünf Minuten einen Alarm, der dir genau sagt, was wo schiefging – mit Link zum Nachsehen.
So baust du ihn:
Error Trigger
→ Slack / Telegram / E-Mail:
"⚠️ Workflow »{{$json.workflow.name}}« fehlgeschlagen
Fehler: {{$json.execution.error.message}}
Node: {{$json.execution.lastNodeExecuted}}
→ {{$json.execution.url}}"Speichern, benennen (z. B. „Error Handler”) – fertig. Jetzt kommt der entscheidende Schritt, den viele vergessen: Du musst den Fehler-Workflow deinen echten Workflows zuweisen.
In jedem produktiven Workflow: Drei-Punkte-Menü oben rechts → Settings → Error Workflow → „Error Handler” auswählen. Das Beste daran: Ein Error-Workflow lässt sich für beliebig viele Workflows nutzen (n8n Docs). Du baust ihn einmal und weist ihn allen zu.
Zwei nützliche Nachbar-Einstellungen im selben Menü:
- Save failed production executions – aktivieren, damit fehlgeschlagene Läufe gespeichert bleiben und du sie analysieren kannst
- Save execution progress – speichert den Fortschritt, sodass du nach einem Fehler an der Fehlerstelle fortsetzen kannst (kostet etwas Latenz)
Wichtig zu wissen: Der Error-Trigger feuert nur bei automatischen Ausführungen, nicht wenn du einen Workflow manuell testest. Das steht so in der Doku – teste den Alarm also über einen echten Trigger, nicht über den „Test workflow”-Button.
Ebene 2: Fehler auf Node-Ebene abfangen
Nicht jeder Fehler soll gleich den ganzen Workflow stoppen. Auf Node-Ebene hast du drei Werkzeuge.
Retry On Fail – gegen temporäre Fehler
Viele Fehler sind vorübergehend: eine API antwortet kurz nicht, ein Rate-Limit greift für eine Sekunde. Dafür gibt es im Settings-Tab jedes Nodes den Schalter Retry On Fail. Ist er aktiv, wiederholt der Node den Vorgang automatisch, bevor er aufgibt. Mit Wait Between Tries (ms) stellst du die Wartezeit zwischen den Versuchen ein (n8n Docs).
Ein Beispiel: Erlaubt eine API einen Request pro Sekunde, setzt du „Wait Between Tries” auf 1000 ms – dann läuft der Node nicht ins Rate-Limit.
Hinweis: Die n8n-Oberfläche begrenzt Retry aktuell auf max. 5 Versuche und max. 5000 ms Wartezeit (Stand 2025/26). Brauchst du längere Pausen oder mehr Versuche, nutzt du einen separaten Wait-Node oder eine eigene Schleifen-Logik.
On Error – was passiert, wenn’s schiefgeht
Ebenfalls im Settings-Tab: die Option On Error mit drei Möglichkeiten (n8n Docs):
| Einstellung | Verhalten | Wann einsetzen |
|---|---|---|
| Stop Workflow (Standard) | Bricht den ganzen Workflow ab | Kritische Schritte, ohne die nichts weitergehen darf |
| Continue | Läuft trotz Fehler zum nächsten Node weiter | Unwichtige Nebenschritte (z. B. optionales Logging) |
| Continue (using error output) | Trennt fehlerhafte Datensätze in einen zweiten Ausgang | Batch-Verarbeitung – ein schlechtes Item soll nicht alle killen |
Die dritte Option ist die mächtigste. Verarbeitest du 200 Datensätze und einer ist fehlerhaft, willst du nicht, dass die anderen 199 auch scheitern. Continue (using error output) erzeugt am Node einen zweiten Ausgang: Die guten Items laufen normal weiter, die fehlerhaften landen im Fehler-Zweig – wo du sie loggen, sammeln oder separat benachrichtigen kannst.
Stop And Error – bewusst kontrolliert abbrechen
Manchmal willst du, dass ein Workflow abbricht – etwa wenn eine Validierung fehlschlägt („Kunde hat keine E-Mail-Adresse”). Dafür gibt es den Stop And Error-Node (n8n Docs). Du platzierst ihn hinter einen IF-Check und gibst eine eigene Fehlermeldung aus. Der Clou: Dieser bewusst ausgelöste Fehler landet ebenfalls in deinem zentralen Error-Workflow – du wirst also auch über deine eigenen Abbruch-Bedingungen informiert.
Ebene 3: Monitoring der Instanz
Alarme sagen dir, wenn etwas kaputt ist. Monitoring sagt dir, wie es läuft – auch wenn nichts brennt.
Die Executions-Liste ist dein erster Blick. Unter Overview → Executions filterst du nach Status: Failed, Running, Success, Waiting. Fehlgeschlagene Läufe kannst du direkt erneut ausführen – Retry with currently saved workflow (mit deinen Korrekturen) oder Retry with original workflow (unveränderter Stand) (n8n Docs). Zum Debuggen lädst du die Fehlerdaten per Debug in editor direkt in den Editor.
Für self-hosted Instanzen (etwa nach meiner Hetzner-Anleitung) kommen echte Monitoring-Endpunkte dazu:
| Endpunkt / Variable | Funktion |
|---|---|
/healthz | HTTP 200 = Instanz erreichbar |
/healthz/readiness | HTTP 200 = Datenbank verbunden und bereit |
/metrics | Prometheus-Metriken (nur self-hosted, nicht in n8n Cloud) |
N8N_METRICS=true | Aktiviert den Metrics-Endpunkt (Standard: aus) |
Mit /healthz bindest du n8n in einen Uptime-Monitor ein (z. B. Uptime Kuma), der dich alarmiert, wenn die Instanz selbst nicht mehr antwortet. Mit /metrics und N8N_METRICS=true bekommst du Prometheus-Kennzahlen für ein Grafana-Dashboard – im Queue-Modus zusätzlich über N8N_METRICS_INCLUDE_QUEUE_METRICS=true (n8n Docs).
Das eingebaute Log Streaming (Logs live an externe Systeme senden) ist der Enterprise-Version vorbehalten (n8n Docs). Für Selbstständige reicht in aller Regel die Kombination aus zentralem Error-Workflow + /healthz-Uptime-Monitor vollkommen aus.
Deine Fehlerbehandlungs-Checkliste
Bevor ein Workflow „produktiv” ist, sollte er diese Punkte erfüllen:
- Zentraler Error-Workflow gebaut und dem Workflow zugewiesen
- Save failed production executions aktiviert
- Retry On Fail an allen Nodes, die externe APIs aufrufen
- Continue (using error output) überall dort, wo du Datensätze in Batches verarbeitest
- Stop And Error hinter kritischen Validierungen
- Bei self-hosted:
/healthzin einem Uptime-Monitor - Ein Test-Fehler ausgelöst, um zu prüfen, dass der Alarm wirklich ankommt
Punkt 7 ist der, den fast alle vergessen. Ein Alarm, den du nie getestet hast, ist kein Alarm – er ist eine Hoffnung.
Häufige Fragen zu n8n Fehlerbehandlung
Muss ich für jeden Workflow einen eigenen Error-Workflow bauen? Nein. Du baust einen einzigen Error-Workflow und weist ihn allen anderen zu (Settings → Error Workflow). Er funktioniert für beliebig viele Workflows gleichzeitig.
Warum feuert mein Error-Trigger beim Testen nicht? Weil der Error-Trigger nur bei automatischen Ausführungen anspringt, nicht beim manuellen „Test workflow”. Löse einen echten Trigger aus (Webhook, Schedule), um den Fehler-Workflow zu testen.
Was ist der Unterschied zwischen „Continue” und „Continue (using error output)”? „Continue” leitet auch fehlerhafte Items über den normalen Ausgang weiter – der Fehler geht dabei unter. „Continue (using error output)” trennt sie in einen eigenen Fehler-Zweig, sodass du sie gezielt behandeln kannst. Für sauberes Error-Handling ist fast immer der Fehler-Output die richtige Wahl.
Wie oft wiederholt Retry On Fail einen Node? So oft, wie du unter „Max. Tries” einstellst – die Oberfläche erlaubt aktuell bis zu 5 Versuche, mit bis zu 5000 ms Wartezeit dazwischen. Brauchst du mehr, baust du die Wiederholung mit einem Wait-Node selbst.
Bekomme ich Monitoring auch ohne Enterprise-Lizenz?
Ja. Executions-Liste, manuelles Retry, /healthz, /healthz/readiness und die Prometheus-Metriken (/metrics) stehen self-hosted ohne Enterprise zur Verfügung. Nur das eingebaute Log Streaming ist Enterprise-only.
Reicht der Error-Workflow oder brauche ich zusätzlich Monitoring?
Für die meisten Selbstständigen reicht der zentrale Error-Workflow plus ein /healthz-Uptime-Monitor. Prometheus/Grafana lohnt sich erst, wenn du viele Workflows produktiv betreibst und Trends sehen willst.
Nächste Schritte
Wenn du n8n noch nicht selbst betreibst, ist die Self-Hosting-Anleitung auf Hetzner der Startpunkt – dort bekommst du auch Zugriff auf die Health-Check- und Metrics-Endpunkte. Die Grundlagen für deinen ersten Workflow stehen im n8n Einsteiger-Guide, und praxisnahe Automationen zeigt n8n Automationen für Selbstständige.
Willst du deine Automationen produktionssicher aufsetzen – mit Fehlerbehandlung, die dich nie im Dunkeln lässt? Schreib mir.
Quellen
- n8n Docs: Error Trigger Node – abgerufen 2026-07-23
- n8n Docs: Handle errors gracefully – abgerufen 2026-07-23
- n8n Docs: Configure workflow settings – abgerufen 2026-07-23
- n8n Docs: Work with nodes (On Error) – abgerufen 2026-07-23
- n8n Docs: Handle rate limits (Retry On Fail) – abgerufen 2026-07-23
- n8n Docs: Stop And Error Node – abgerufen 2026-07-23
- n8n Docs: View all executions – abgerufen 2026-07-23
- n8n Docs: Monitor n8n (healthz, metrics) – abgerufen 2026-07-23
- n8n Docs: Enable Prometheus metrics – abgerufen 2026-07-23
- DATAVERSITY: Putting a Number on Bad Data (Gartner-Schätzung) – abgerufen 2026-07-23
Über den Autor
Ich bin Chris Schweigler, n8n-Experte aus Österreich. Ich baue Automatisierungen für Selbstständige, die auch im Fehlerfall zuverlässig bleiben – mit sauberer Fehlerbehandlung und Monitoring, damit nichts still im Nichts verschwindet. Kontakt
Du willst das in deinem Business umsetzen?
Ich zeige dir, welche Automationen für dich am meisten Zeit und Geld sparen – in einem kostenlosen Erstgespräch.