n8n-Monitoring: Fehler, Laufzeiten und fehlgeschlagene Executions

Das Problem: Automatisierung ohne Kontrollblick

Ein Workflow, der einmal läuft, ist schnell gebaut. Ein Workflow, dem man vertrauen kann, weil man weiß, ob und wie oft er scheitert, ist eine andere Aufgabe — und genau die wird in vielen n8n-Projekten übersprungen. Das typische Muster: Der Workflow funktioniert im Test, geht live, läuft ein paar Wochen unauffällig — und irgendwann fällt auf, dass seit Tagen keine Bestellungen mehr im ERP ankommen, weil eine API im Hintergrund ihre Antwortstruktur geändert hat. Niemand hat es bemerkt, weil niemand hingeschaut hat.

Dieser Artikel richtet sich an Geschäftsführung, Operations, IT und Fachbereich in KMU, die n8n-Workflows bereits produktiv nutzen oder kurz davorstehen — und wissen wollen, welche Metriken zählen, wie man fehlgeschlagene Runs erkennt, wie Error Workflows funktionieren, wie lange Ausführungsdaten aufbewahrt werden sollten und wie ein Incident konkret abläuft. Er ist Teil unserer Übersicht zu Automatisierungstools und Integrationen und setzt voraus, dass mindestens ein Workflow bereits läuft; wie man n8n grundsätzlich aufsetzt, behandelt der Artikel „Was ist n8n?” in dieser Kategorie.

Monitoring ist dabei kein Zusatzprojekt, das man sich für später aufhebt. Es ist der Unterschied zwischen einer Automatisierung, die Vertrauen verdient, und einer, die im Zweifel niemand mehr manuell gegenprüft — mit den entsprechenden Folgen, wenn genau dann etwas schiefgeht.

Begriffe kurz geklärt

• Execution: Ein einzelner Durchlauf eines Workflows, ausgelöst durch Trigger, Zeitplan oder manuell. Jede Execution hat einen Status: Success, Failed, Running oder Waiting.
• Error Workflow: Ein separater n8n-Workflow, der automatisch startet, wenn ein anderer Workflow fehlschlägt — die zentrale Alarmierungsmechanik von n8n.
• Error Trigger: Der Node, mit dem ein Error Workflow beginnen muss. Er liefert die Fehlerdetails der gescheiterten Execution als strukturierte Daten.
• Retention / Pruning: Die Regel, wie lange abgeschlossene Executions gespeichert bleiben, bevor n8n sie automatisch löscht.
• Health-Check: Ein technischer Endpunkt, über den externe Systeme (Load Balancer, Monitoring-Tools) prüfen, ob die n8n-Instanz selbst erreichbar und betriebsbereit ist — unabhängig davon, ob einzelne Workflows fehlschlagen.

Abgrenzung: n8n-Monitoring hat zwei unterschiedliche Ebenen, die oft vermischt werden. Die eine ist Workflow-Monitoring: Schlagen einzelne Automatisierungen fehl, und warum? Die andere ist Infrastruktur-Monitoring: Läuft die n8n-Instanz selbst noch, hat sie genug Ressourcen, ist die Datenbank erreichbar? Für Self-Hosting braucht ihr beides; bei n8n Cloud verantwortet der Hersteller die Infrastrukturebene, Workflow-Monitoring bleibt eure Aufgabe — dazu mehr im Artikel zu n8n Cloud versus Self-Hosting in dieser Kategorie.

Welche Metriken sind relevant?

Nicht jede verfügbare Kennzahl ist gleich wichtig. Für die meisten KMU-Setups reichen vier Metriken, um zu wissen, ob eine Automatisierung gesund läuft:

Metrik	Was sie zeigt	Wo zu finden	Warum relevant
Fehlgeschlagene Executions (absolut)	Anzahl der Runs mit Status „Failed” in einem Zeitraum	Executions-Liste, gefiltert nach Status	Direktes Signal für akute Probleme
Failure Rate	Anteil fehlgeschlagener an allen produktiven Executions eines Workflows	Insights-Dashboard (Pro-Plan aufwärts)	Erkennt schleichende Verschlechterung, nicht nur Einzelfälle
Laufzeit pro Workflow	Durchschnittliche Ausführungsdauer, inklusive Wartezeiten an Wait-Nodes	Insights-Dashboard bzw. einzelne Execution-Details	Steigende Laufzeit ist oft ein Frühwarnzeichen, bevor etwas ganz ausfällt
Warteschlangen-Tiefe (Queue Mode)	Aktive, wartende und fehlgeschlagene Jobs in der Bull-Queue	Prometheus-Metriken n8n_scaling_mode_queue_jobs_*	Zeigt, ob Worker mit dem Volumen mithalten
Instanz-Erreichbarkeit	Ist n8n selbst erreichbar und betriebsbereit (DB verbunden, Migrationen durchgelaufen)	/healthz und /healthz/readiness	Unterscheidet „ein Workflow ist kaputt” von „die ganze Plattform ist weg”

Eigene Metrik-Priorisierung Philogic Labs auf Basis der n8n-Dokumentation zu Executions, Insights und Prometheus-Metriken.

Die Reihenfolge in der Tabelle ist auch eine Priorisierung: Wer klein anfängt, richtet zuerst einen Error Workflow ein (fehlgeschlagene Executions), dann einen Health-Check auf Infrastrukturebene. Failure Rate, Laufzeittrends und Queue-Metriken sind sinnvoll, sobald mehrere Workflows produktiv laufen oder eine bezahlte Plan-Stufe mit Insights-Zugriff vorhanden ist — für einen einzelnen Workflow in der Anfangsphase ist der Aufwand meist nicht gerechtfertigt.

Wichtig zur Einordnung: Das Insights-Dashboard mit vollem Funktionsumfang ist laut n8n-Dokumentation den bezahlten Plänen vorbehalten (Pro-Plan zeigt 7- und 14-Tage-Fenster, Business zusätzlich 24-Stunden- und 30-Tage-Ansichten, Enterprise bis zu 90 Tage, 6 Monate und ein Jahr rückblickend); die Community Edition sieht nur die Executions-Liste ohne aggregierte Auswertung. Wer selbst hostet und trotzdem aggregierte Metriken will, aktiviert stattdessen den Prometheus-Endpunkt (N8N_METRICS=true) und wertet die Daten in einem eigenen Grafana- oder Monitoring-Stack aus.

Wie erkennt man fehlgeschlagene Runs?

Zwei Wege, die sich ergänzen, nicht ersetzen:

1. Manuell in der Executions-Liste. Über die Übersicht lassen sich alle Executions nach Workflow, Status (Failed, Running, Success, Waiting) und Startzeitraum filtern. Das ist die richtige Stelle für die stichprobenartige Kontrolle und für die Analyse eines konkreten Fehlers — jede Execution zeigt, an welchem Node sie gescheitert ist und mit welcher Fehlermeldung. Für die laufende Überwachung ist die manuelle Liste aber ungeeignet: Sie erfordert, dass jemand regelmäßig aktiv nachschaut, und genau das passiert in der Praxis selten zuverlässig, sobald der Alltag dazwischenkommt.

2. Automatisiert über einen Error Workflow. Das ist die eigentliche Lösung für produktive Workflows: n8n benachrichtigt euch aktiv, statt dass ihr nachschauen müsst. Wie das konkret aufgesetzt wird, zeigt der nächste Abschnitt.

Ein praktischer Hinweis aus eigener Erfahrung: Bei kritischen Workflows lohnt es sich, zusätzlich zum Fehlerfall auch „stille” Ausfälle zu bedenken — etwa einen zeitgesteuerten Workflow, der einfach gar nicht mehr ausgeführt wird, weil er versehentlich deaktiviert wurde. Ein deaktivierter Workflow erzeugt keine fehlgeschlagene Execution und triggert damit auch keinen Error Workflow. Für Kern-Workflows ist deshalb ein einfacher externer Heartbeat-Check sinnvoll: ein separater, sehr einfacher Workflow, der regelmäßig ein Lebenszeichen sendet, dessen Ausbleiben selbst zum Alarmsignal wird.

Wie funktionieren Error Workflows?

Ein Error Workflow ist ein normaler n8n-Workflow mit einer speziellen Rolle: Er beginnt mit dem Error-Trigger-Node und wird nicht direkt aufgerufen, sondern automatisch gestartet, wenn ein anderer Workflow fehlschlägt.

Einrichtung in vier Schritten:

1. Neuen Workflow anlegen, als ersten Node den Error Trigger einfügen, sinnvoll benennen (z. B. „Error Handler – Produktion”) und speichern.
2. Im zu überwachenden Workflow unter Einstellungen (Options → Settings) das Feld „Error workflow” öffnen und den soeben erstellten Workflow auswählen.
3. Im Error Workflow die eigentliche Benachrichtigungslogik ergänzen — typischerweise ein Node, der eine E-Mail oder eine Nachricht in einen Team-Chat schickt.
4. Denselben Error Workflow bei Bedarf auch anderen Workflows als Fehlerbehandlung hinterlegen — n8n erlaubt laut Dokumentation die gemeinsame Nutzung eines Error Workflows für mehrere überwachte Workflows.

Was der Error Trigger bekommt: Bei einem Fehler liefert der Error Trigger unter anderem die Fehlermeldung, den Stack Trace, den Namen des Nodes, an dem es scheiterte, sowie Workflow-ID und -Name. Details wie Execution-ID und -URL sind laut n8n-Dokumentation nur verfügbar, wenn die Execution in der Datenbank gespeichert wurde. Scheitert bereits der Trigger-Node selbst statt eines späteren Schritts im Workflow, sieht die Datenstruktur etwas anders aus — mehr Informationen stecken dann im trigger-Objekt, weniger im execution-Objekt.

Einschränkung, die in der Praxis öfter zu Verwirrung führt: Der Error Trigger lässt sich laut Dokumentation nicht durch einen manuellen Testlauf auslösen — er reagiert ausschließlich auf Fehler in automatisch laufenden Workflows. Wer die Alarmierungskette testen will, braucht einen echten fehlgeschlagenen automatischen Run oder provoziert den Fehler gezielt, etwa über den Stop-And-Error-Node, der Ausführungen bewusst mit einer definierten Fehlermeldung abbrechen und dadurch den Error Workflow auslösen kann.

Wie plant man Retention?

Retention klingt nach einem reinen Infrastrukturthema, ist aber eine Entscheidung mit fachlichen Folgen: Wie weit lässt sich ein Fehler im Nachhinein noch nachvollziehen?

Selbst gehostetes n8n löscht abgeschlossene Executions standardmäßig automatisch (Pruning ist per Voreinstellung aktiv), gesteuert über zwei unabhängige Grenzen:

• Alter: Executions, die älter als EXECUTIONS_DATA_MAX_AGE Stunden sind, werden gelöscht — Standardwert 336 Stunden, also 14 Tage.
• Anzahl: Übersteigt die Gesamtzahl gespeicherter Executions EXECUTIONS_DATA_PRUNE_MAX_COUNT (Standardwert 10.000), löscht n8n von der ältesten Execution beginnend, bis die Grenze wieder eingehalten ist.

Beide Werte lassen sich per Umgebungsvariable anpassen. Ein EXECUTIONS_DATA_HARD_DELETE_BUFFER (Standard: 1 Stunde) sorgt zusätzlich dafür, dass gerade abgeschlossene Executions nicht sofort verschwinden, solange noch jemand aktiv an einem Workflow debuggt. Laufende, wartende oder neu angelegte Executions sind von der Löschung grundsätzlich ausgenommen, ebenso Executions, die manuell mit Tags oder Bewertungen versehen wurden.

Für die Praxis bedeutet das eine bewusste Entscheidung statt der Standardeinstellung:

• 14 Tage reichen, wenn Fehler in der Regel innerhalb weniger Tage auffallen und behoben werden und keine Nachvollziehbarkeitspflichten über längere Zeiträume bestehen.
• Längere Retention lohnt sich, wenn ein Workflow selten läuft (z. B. monatliche Abrechnungsläufe), wenn Fehler häufig erst spät auffallen (etwa weil Kunden sich erst nach Wochen melden) oder wenn ihr aus Audit-Gründen nachweisen müsst, was wann verarbeitet wurde.
• Speicherbedarf mitdenken: Längere Retention bedeutet mehr Daten in der Datenbank, insbesondere bei Workflows mit großen Payloads. Bei selbst betriebenem SQLite gibt die Dokumentation den Hinweis, dass gelöschte Daten den Speicherplatz nicht automatisch freigeben, sondern für künftige Executions wiederverwenden — für echte Speicherplatzfreigabe ist ein VACUUM nötig.

Ergänzend gibt n8n seit den jüngeren 2.x-Versionen laut Release Notes die Möglichkeit, Executions über OpenTelemetry-Traces zu verfolgen (Workflow-ID, Status, Dauer, Node-Anzahl je Trace-Span) und im Enterprise-Kontext Execution-Daten in der Oberfläche zu maskieren, bis sie gezielt eingesehen werden — beides zusätzliche Bausteine für Instanzen mit höheren Nachvollziehbarkeits- oder Datenschutzanforderungen, aber kein Ersatz für eine bewusst gesetzte Grundretention.

Wie bearbeitet man Incidents?

Ein Fehler-Alarm ist erst der Anfang. Ohne festen Ablauf danach bleibt jede Reaktion Zufall — der eine kümmert sich sofort, der andere erst Tage später, wenn überhaupt. Fünf Schritte, die sich in Projekten bewährt haben:

1. Erkennen. Der Error Workflow (oder Heartbeat-Check) meldet den Fehler an einen definierten Kanal — nicht an eine einzelne Person, sondern an einen Team-Chat oder eine Gruppenadresse, damit Abwesenheit keine Lücke reißt.

2. Einordnen. Einzelfall oder Muster? Ein einmaliger Timeout bei einer externen API ist selten dramatisch. Drei Fehlermeldungen zum selben Node innerhalb einer Stunde deuten auf ein strukturelles Problem hin — eine geänderte API, ein abgelaufenes Zugangstoken, ein erreichtes Rate Limit.

3. Eingrenzen. Welche Datensätze sind betroffen? Über die Executions-Liste, gefiltert nach Zeitraum und Status, lässt sich meist schnell klären, seit wann und wie oft ein Workflow scheitert und welche konkreten Vorgänge (Bestellungen, Tickets, Datensätze) dadurch nicht verarbeitet wurden.

4. Beheben oder wiederholen. Für vorübergehende Fehler bietet n8n in der Execution-Ansicht eine Retry-Funktion — wahlweise mit dem ursprünglichen oder dem inzwischen aktualisierten Workflow. Für dauerhafte Fehler (falsche Zugangsdaten, geänderte Datenstruktur) hilft Wiederholen nicht; hier muss der Workflow selbst angepasst werden, bevor erneut versucht wird.

5. Dokumentieren. Was war die Ursache, was wurde geändert, wer war betroffen? Ohne diesen Schritt wiederholt sich derselbe Fehler in sechs Monaten, und niemand erinnert sich mehr an die Lösung von letztem Mal. Eine kurze Notiz reicht — entscheidend ist, dass sie überhaupt existiert.

Wer das reproduzierbar aufsetzen will, kann sich am folgenden Ablauf orientieren:

Fehlgeschlagene Execution
        │
        ▼
   Error Trigger (n8n)
        │
        ▼
  Alarmierung an Team-Kanal
  (E-Mail / Chat, mit Fehlermeldung + Node)
        │
        ▼
   Einordnen: Einzelfall oder Muster?
        │
   ┌────┴────┐
   ▼         ▼
Einzelfall  Muster (mehrfach, gleicher Node)
   │              │
   ▼              ▼
Retry oder    Ursache klären (API, Zugangsdaten,
manuell       Datenstruktur, Rate Limit)
beheben              │
   │                 ▼
   │           Workflow anpassen, dann Retry
   │                 │
   └────────┬────────┘
            ▼
      Betroffene Datensätze
      identifizieren & nachziehen
            │
            ▼
       Kurz dokumentieren
   (Ursache, Fix, betroffener Zeitraum)

Eigenes Incident-Ablaufdiagramm Philogic Labs, abgeleitet aus n8n-Projektpraxis.

Ein Punkt aus der BSI-Handreichung zu generativer KI lässt sich direkt auf n8n-Workflows übertragen, die KI-Schritte enthalten (z. B. Textgenerierung, Klassifikation durch ein Sprachmodell innerhalb des Workflows): KI-Ausgaben sollten laut BSI validiert werden, bevor sie ungeprüft an Backend-Systeme weitergegeben werden. Für Incident-Handling heißt das konkret: Ein „Fehler” bei einem KI-gestützten Workflow-Schritt ist nicht nur eine technische Exception, sondern kann auch eine plausibel aussehende, aber inhaltlich falsche Ausgabe sein, die kein Error Trigger automatisch erkennt. Für solche Schritte lohnt sich zusätzlich zur technischen Fehlerbehandlung eine inhaltliche Stichprobenprüfung.

Umsetzung: Monitoring in drei Stufen aufbauen

Nicht jedes Setup braucht sofort alles. Ein pragmatischer Ausbau in drei Stufen:

Stufe 1 – Basis (für jeden produktiven Workflow): Ein zentraler Error Workflow mit Benachrichtigung an einen Team-Kanal, hinterlegt bei allen produktiven Workflows. Aufwand: ein bis zwei Stunden einmalig, dann nur noch Zuweisung bei neuen Workflows.

Stufe 2 – Selbst gehostet, mehrere kritische Workflows: Zusätzlich Health-Checks (/healthz/readiness) in eure bestehende Server-Überwachung einbinden, Retention bewusst auf eure Nachvollziehbarkeitsanforderungen setzen, und bei Queue-Betrieb den Prometheus-Endpunkt für Warteschlangen-Metriken aktivieren. Aufwand: ein bis drei Tage, abhängig vom vorhandenen Monitoring-Stack.

Stufe 3 – Viele Workflows, mehrere Teams: Insights-Dashboard (erfordert Pro-Plan oder höher) für Failure-Rate- und Laufzeittrends über alle Workflows hinweg, ergänzt um Log Streaming an ein zentrales SIEM- oder Logging-System und OpenTelemetry-Tracing für tiefergehende Diagnose einzelner Executions. Sinnvoll, sobald Automatisierung kein Nebenprojekt mehr ist, sondern mehrere Geschäftsprozesse trägt.

Der häufigste Fehler in der Praxis ist nicht die falsche Stufe, sondern gar keine: Stufe 1 allein — ein sauber konfigurierter Error Workflow — deckt bei den meisten KMU-Setups den größten Teil des Risikos ab und ist in einem Nachmittag umgesetzt.

Risiken und Grenzen

• Ein Error Workflow ersetzt keine Prozessverantwortung. Die Benachrichtigung sagt, dass etwas fehlgeschlagen ist — nicht, wer sich darum kümmert. Ohne benannte Zuständigkeit verhallt auch die beste Alarmierung.
• Alarmmüdigkeit ist real. Ein Error Workflow, der bei jedem vorübergehenden Netzwerk-Hänger sofort eine E-Mail verschickt, führt dazu, dass Meldungen irgendwann ungelesen bleiben. Für Fehler, bei denen ohnehin automatisch wiederholt wird, kann es sinnvoll sein, erst nach mehreren gescheiterten Versuchen zu alarmieren.
• Der Error Trigger lässt sich nicht manuell testen. Wer die Alarmierungskette prüfen will, muss einen echten automatischen Fehler erzeugen — etwa gezielt über den Stop-And-Error-Node — statt sich auf einen ungetesteten Aufbau zu verlassen.
• Insights und Log Streaming sind an Pläne gebunden. Wer die Community Edition selbst hostet, hat weder aggregiertes Dashboard noch Log-Streaming-Ziele im Standardumfang und muss auf die Executions-Liste, den Prometheus-Endpunkt und eigene Auswertung ausweichen.
• Monitoring erkennt technische Fehler, keine inhaltlichen. Ein Workflow, der erfolgreich durchläuft, aber falsche oder unsinnige Daten produziert — etwa nach einer stillen API-Änderung oder bei einem fehlerhaften KI-Ausgabe-Schritt —, erscheint in der Executions-Liste als „Success”. Dagegen hilft nur eine inhaltliche Stichprobenprüfung, die kein technisches Monitoring ersetzt.

Checkliste: n8n-Monitoring produktiv aufsetzen

1. Für jeden produktiven Workflow ist ein Error Workflow in den Einstellungen hinterlegt, kein Workflow läuft ohne Fehlerbehandlung.
2. Der Error Workflow benachrichtigt einen Team-Kanal, nicht nur eine einzelne Person.
3. Kritische zeitgesteuerte Workflows haben zusätzlich einen Heartbeat-Check, damit auch stille Ausfälle (deaktivierter Workflow, ausbleibender Trigger) auffallen.
4. Bei Self-Hosting: Health-Check-Endpunkte sind in die bestehende Server-Überwachung eingebunden.
5. Retention ist bewusst gesetzt — nicht die Standardeinstellung unreflektiert übernommen, sondern an Nachvollziehbarkeitsbedarf und Speicherplatz angepasst.
6. Es gibt einen klaren Incident-Ablauf: erkennen, einordnen, eingrenzen, beheben oder wiederholen, dokumentieren — mit benannter Zuständigkeit.
7. Die Alarmierungskette wurde getestet — über einen bewusst provozierten Fehler, nicht nur angenommen.
8. Bei KI-Schritten im Workflow gibt es zusätzlich zur technischen Fehlerbehandlung eine Stichprobenprüfung der inhaltlichen Qualität.
9. Bei mehreren kritischen Workflows ist geklärt, ob Insights, Prometheus-Metriken oder Log Streaming den nächsten sinnvollen Ausbauschritt darstellen.

Wenn ihr eure n8n-Workflows produktiv betreibt und unsicher seid, welche Monitoring-Stufe zu eurer Situation passt, ordnen wir das in unserer KI- und Automatisierungsberatung gemeinsam ein; wenn euer Team Error Workflows, Retention und Incident-Handling künftig selbst betreiben soll, vermitteln unsere Schulungen genau diese Betriebsroutine.