n8n-Workflows überwachen: Error-Workflows, Healthchecks und Monitoring-Dienste im Vergleich

Um einen n8n-Workflow zuverlässig zu überwachen und bei einem Fehler wirklich benachrichtigt zu werden, reicht der eingebaute Error-Trigger allein nicht: Er reagiert nur auf Fehler, die n8n selbst erkennt, also fehlgeschlagene Ausführungen oder einen scheiternden Trigger – nicht auf einen Workflow, der grün durchläuft, aber keine oder falsche Daten liefert. Dieser Vergleich behandelt vier Wege: n8n-eigene Error-Workflows, externe Healthcheck- und Uptime-Dienste, einen selbstgebauten Meta-Workflow und einen Managed-Dienst; dazu kommen die Status-Endpunkte /healthz, /healthz/readiness und /metrics, die n8n selbst mitliefert.

Vergleich auf einen Blick

Option	Was sie fängt	Was sie nicht fängt	Aufwand
n8n Error-Workflow	Ausführungen, die n8n als Fehler protokolliert	Grün beendete Runs ohne Daten, Totalausfall der Instanz, zeitgesteuerte Läufe, die n8n übersprungen hat (etwa nach einem Neustart)	Gering – einmal je Workflow einrichten
Externer Healthcheck-/Uptime-Dienst	Fehlender oder verspäteter Ping, Instanz nicht erreichbar	Ob die verarbeiteten Daten inhaltlich stimmen	Gering – Dienst einrichten, Ping-Node in jeden Workflow
Eigenbau-Meta-Workflow	Frei definierbar, z. B. Executions ohne Erfolg seit X Stunden	Was die eigene Prüflogik nicht abdeckt; teilt den Ausfallpunkt der Instanz	Hoch – Bau und laufende Pflege
Managed-Dienst	Was der Anbieter vertraglich zusagt	Was nicht im Leistungsumfang steht	Laufende Kosten, wenig Eigenbetrieb
n8n-Endpunkte /healthz und /metrics	Instanz antwortet nicht, Datenbank nicht bereit; mit /metrics (nur Self-Hosting) Zählerstände wie fehlgeschlagene Ausführungen (mit Zusatzschalter)	Einzelne Workflows, die grün ohne Daten enden; meldet nichts, solange niemand von außen abfragt	Gering für /healthz; /metrics braucht ein eigenes Monitoring-System

Die vier Wege im Detail

1. n8n-eigene Error-Workflows

n8n stellt dafür den Error-Trigger-Node bereit: Sie legen einen eigenen Workflow an, der als erste Node einen Error-Trigger hat, und tragen diesen Workflow in den Einstellungen des zu überwachenden Workflows unter „Error Workflow“ ein. Schlägt eine Ausführung fehl, ruft n8n automatisch diesen Fehler-Workflow auf und übergibt ihm Ausführungs-ID und Ausführungs-URL, sofern die Ausführung gespeichert wurde, und – bei einem Retry – die ID der ursprünglich fehlgeschlagenen Ausführung. Wichtig beim Testen: Laut n8n-Dokumentation löst der Error-Trigger nur aus, wenn ein automatisch gestarteter Workflow fehlschlägt, nicht bei einem manuellen Testlauf.

Drei Lücken sind für die Praxis wichtiger als die Funktion selbst:

Ein einzelner Node, dessen Fehlerverhalten („On Error“) auf „Continue“ oder „Continue (using error output)“ statt auf „Stop Workflow“ gestellt ist, lässt den Gesamt-Workflow trotz eines Fehlers in diesem Schritt weiterlaufen. Der Error-Trigger feuert dann nicht: Im n8n-Quellcode (Stand 27. September 2026) wird der Error-Workflow nur aufgerufen, wenn die Ausführung insgesamt einen Fehler trägt, und ein Node mit einer dieser beiden Einstellungen setzt die Ausführung fort, statt sie mit Fehler zu beenden.

Ein Workflow, der zum Beispiel eine leere Ergebnisliste von einer API zurückbekommt und deshalb keine Datensätze weiterverarbeitet, ist aus n8ns Sicht kein Fehler – die Ausführung endet grün, obwohl kein einziger Datensatz geflossen ist. Wer das fangen will, muss die Prüfung selbst einbauen: eine IF-Node, die prüft, ob das Ergebnis leer ist, und im leeren Zweig eine Stop-And-Error-Node, die die Ausführung aktiv zum Fehler macht und damit erst den Error-Trigger auslöst. Aktivieren Sie dafür am Node davor die Einstellung „Always Output Data“, denn ohne eingehende Items führt n8n die IF-Node gar nicht aus. Bei leerem Ergebnis kommt dann ein einzelnes leeres Item an; prüfen Sie deshalb, ob ein Pflichtfeld wie die ID fehlt, nicht die Zahl der Items.

Und das Feld „Error Workflow“ ist eine Einstellung pro Workflow, keine instanzweite Voreinstellung – ein neu angelegter Workflow, bei dem das Feld nicht gesetzt wird, hat keine Fehlerbenachrichtigung, sofern er nicht selbst einen Error-Trigger enthält.

Dazu kommt ein struktureller Punkt, der sich unmittelbar aus der Architektur ergibt: Läuft die komplette n8n-Instanz nicht mehr – Server abgestürzt, Prozess beendet –, kann auch kein Error-Workflow mehr feuern, weil er Teil derselben Instanz ist, die gerade ausfällt. Für diesen Fall braucht es eine Prüfung, die außerhalb von n8n läuft.

2. Externe Healthcheck- und Uptime-Dienste

Healthcheck-Dienste wie healthchecks.io prüfen n8n von außen, unabhängig davon, ob die Instanz selbst noch läuft. Das Grundprinzip ist ein Dead-Man’s-Switch: Ihr Workflow ruft am Ende einer erfolgreichen Ausführung eine Ping-URL auf; meldet sich der Workflow innerhalb eines vorher festgelegten Zeitfensters nicht, schlägt der Dienst Alarm. Zusätzlich kann ein Workflow über die Endung /fail der Ping-URL einen Fehler aktiv melden, etwa aus dem Leer-Zweig der IF-Prüfung aus Abschnitt 1.

Wie viele Checks kostenlose und bezahlte Konten erlauben, nennt die Preisseite von healthchecks.io. Healthchecks ist Open Source unter der BSD-3-Lizenz, Quellcode und Anleitung zum Selbstbetrieb liegen auf GitHub (github.com/healthchecks/healthchecks). Betreiben Sie den Dienst selbst, prüfen Sie, dass er nicht auf demselben Server läuft wie n8n – sonst fällt der Wächter mit der Instanz zusammen aus.

Klassische Uptime-Monitore arbeiten umgekehrt: Sie rufen von außen eine Adresse auf, etwa den /healthz-Endpunkt von n8n (Abschnitt „Was n8n selbst mitliefert“ unten), und melden, wenn keine Antwort kommt. healthchecks.io schreibt in seiner Dokumentation ausdrücklich, dass es nicht dafür gedacht ist, Websites per HTTP-Abfrage auf Erreichbarkeit zu prüfen. Für den Ping aus einem Workflow und die Abfrage der Instanz brauchen Sie deshalb unter Umständen zwei verschiedene Werkzeuge.

Der Vorteil gegenüber dem n8n-eigenen Error-Workflow: Der Ping hängt nicht an der überwachten Instanz. Fällt der Server komplett aus oder wird ein Workflow versehentlich deaktiviert, bleibt der erwartete Ping aus, und genau das meldet der Dienst, sofern Zeitraum und Karenzzeit des Checks zum Zeitplan passen – das ist die Lücke aus Abschnitt 1. Dasselbe gilt für einen Fall, den die n8n-Dokumentation beschreibt: Mit dem standardmäßigen In-Memory-Scheduler überspringt n8n nach einem Neustart jeden zeitgesteuerten Lauf, dessen Zeitpunkt in die Ausfallzeit fiel. Für einen übersprungenen Lauf gibt es keine fehlgeschlagene Ausführung, auf die ein Error-Workflow reagieren könnte. Beim Self-Hosting gibt es ab n8n 2.36.0 den standardmäßig abgeschalteten Durable Scheduler, den N8N_SCHEDULER_ENABLED=true zusammen mit N8N_USE_WORKFLOW_PUBLICATION_SERVICE=true einschaltet. Innerhalb einer Karenzzeit, standardmäßig eine Minute (N8N_SCHEDULER_MISFIRE_GRACE), startet er einen verpassten Lauf noch verspätet; danach entscheidet die Misfire-Policy. Deren Standard „Don’t Run Missed Executions“ verwirft den Lauf; nachgeholt wird nur bei Schedule-Triggern, die ab n8n 2.36.0 angelegt wurden und in der Option „If Execution Is Missed“ ein Nachholen eingestellt haben. Den externen Ping ersetzt das nicht.

Der Nachteil: Ein Ping bestätigt, dass der Workflow bis zu dieser Node gelaufen ist – nicht, dass die verarbeiteten Daten inhaltlich stimmen. Ein Workflow, der die leere Ergebnisliste aus Abschnitt 1 verarbeitet und trotzdem am Ende brav seinen Ping abschickt, wird von einem Healthcheck-Dienst ebenso wenig erkannt wie vom Error-Trigger. Den leeren Lauf fängt keine der beiden Optionen; dafür braucht es die eingebaute Prüfung aus Abschnitt 1.

3. Eigenbau: ein Meta-Workflow, der die Executions prüft

Die dritte Option baut auf n8n selbst auf: ein separater Meta-Workflow, der die n8n-eigene API oder den nativen n8n-Node abfragt und zum Beispiel prüft, ob ein bestimmter Workflow innerhalb der erwarteten Zeitspanne eine erfolgreiche Ausführung verzeichnet hat, oder ob die Fehlerquote eines Workflows über einen Schwellenwert steigt. Dafür kombinieren Sie einen zeitgesteuerten Trigger (z. B. den Schedule-Trigger) mit dem n8n-eigenen n8n-Node, der als Aktion Workflows und Executions abfragt, auflistet und verwaltet.

Der Vorteil ist frei definierbare Prüflogik ohne einen weiteren Vertrag. Der Nachteil zieht sich durch die anderen Optionen wie ein roter Faden: Ein Meta-Workflow, der auf derselben Instanz läuft, die er überwachen soll, teilt sich mit ihr denselben Ausfallpunkt – fällt die Instanz aus, fällt auch der Wächter aus. Und die Prüflogik muss jemand bauen, testen und pflegen; sie ist damit selbst ein Workflow, der irgendwann eine eigene Fehlerbehandlung braucht. Sinnvoll wird der Eigenbau vor allem in Kombination mit einem externen Ping aus Abschnitt 2, der den Totalausfall der Instanz unabhängig meldet.

4. Managed-Dienste

Die vierte Kategorie sind Dienstleister, die Überwachung und Reaktion ganz oder teilweise übernehmen, statt nur einen Alarm auszulösen. Was ein solcher Dienst abdeckt, ergibt sich nicht aus der Kategorie, sondern aus dem jeweiligen Angebot. Prüfen Sie deshalb drei Punkte: Welche der Ausfallarten aus diesem Artikel erkennt er (Fehler in einer Ausführung, grüner Lauf ohne Daten, Totalausfall der Instanz)? Prüft er von außerhalb Ihrer Instanz oder aus ihr heraus? Und wer tut nach einem Alarm was, bis wann?

Was n8n selbst mitliefert: /healthz, /healthz/readiness und /metrics

Neben dem Error-Workflow bringt n8n drei HTTP-Endpunkte mit, über die ein externes System den Zustand der Instanz abfragen kann (Stand der n8n-Dokumentation: 27. September 2026). Sie beschreiben die Instanz, nicht einzelne Workflows.

Endpunkt	Was er meldet	n8n Cloud	Self-Hosting
/healthz	HTTP 200, wenn die Instanz erreichbar ist; sagt nichts über die Datenbank	Laut Doku verfügbar	Auf dem Hauptserver immer aktiv
/healthz/readiness	HTTP 200 nur, wenn die Datenbank verbunden und migriert ist; im Quellcode sonst HTTP 503	Zur Cloud-Verfügbarkeit sagt die Doku nichts	Auf dem Hauptserver immer aktiv
/metrics	Metriken im Prometheus-Format	Laut Doku nicht verfügbar	Abgeschaltet, bis N8N_METRICS=true gesetzt ist

Beim Self-Hosting steuern Sie die Endpunkte über Umgebungsvariablen:

• N8N_METRICS=true schaltet /metrics ein. Laut Doku können sowohl Main- als auch Worker-Instanzen Metriken liefern. Die Doku rät ausdrücklich, /metrics nicht öffentlich erreichbar zu machen, sondern nur den internen Diensten, die die Daten abholen, weil der Endpunkt sensible Betriebsdaten preisgeben kann.
• N8N_METRICS_INCLUDE_* legt fest, welche zusätzlichen Metriken erscheinen. Für die Workflow-Überwachung ist N8N_METRICS_INCLUDE_MESSAGE_EVENT_BUS_METRICS=true der interessante Schalter: n8n zählt dann Ereignisse als Prometheus-Zähler, im Quellcode (Stand 27. September 2026) wird aus dem Ereignis n8n.workflow.failed der Zähler n8n_workflow_failed_total. Mit N8N_METRICS_INCLUDE_WORKFLOW_ID_LABEL=true lässt er sich je Workflow aufschlüsseln. Im Queue Mode liefert N8N_METRICS_INCLUDE_QUEUE_METRICS=true zusätzlich Metriken zu wartenden, laufenden, abgeschlossenen und fehlgeschlagenen Jobs.
• QUEUE_HEALTH_CHECK_ACTIVE=true braucht es nur im Queue Mode: Auf Worker-Servern sind /healthz und /healthz/readiness standardmäßig abgeschaltet. Die Readiness eines Workers prüft laut Doku die Verbindung zu Datenbank und Redis; den Port legt QUEUE_HEALTH_CHECK_PORT fest (Standard 5678).
• N8N_ENDPOINT_HEALTH ändert den Pfad des Health-Endpunkts (Standard healthz). Die Doku nennt als Anlass Google Cloud Run, das /healthz für eigene Prüfungen belegt.

Zur Auswertung beschreibt die n8n-Doku Grafana, angebunden über Prometheus. Ein Tracing einzelner Workflow- und Node-Ausführungen per OpenTelemetry gibt es seit n8n 2.19.0 als Preview; n8n rät, sich im Produktivbetrieb noch nicht darauf zu verlassen.

Zwei Grenzen gelten für alle drei Endpunkte. Erstens alarmieren sie niemanden von selbst: Erst ein Uptime-Monitor, der /healthz regelmäßig abfragt, oder ein Monitoring-System, das /metrics abholt und für das Sie Alarmregeln festlegen, macht daraus eine Benachrichtigung. Zweitens meldet /healthz auch dann HTTP 200, wenn ein einzelner Workflow deaktiviert ist oder grün ohne Daten endet – dafür bleiben die Wege aus Abschnitt 1 bis 3 nötig.

Welche Kombination passt zu welchem Szenario

• Sie haben wenige, kritische Workflows und wollen sofort bei einem echten Fehler benachrichtigt werden: Richten Sie den n8n-eigenen Error-Workflow für jeden aktiven Workflow einzeln ein und ergänzen Sie die IF-Prüfung mit Stop-And-Error-Node aus Abschnitt 1 an den Stellen, an denen ein leeres Ergebnis wie ein Fehler behandelt werden soll – ein Beispiel ist ein Workflow, der eingehende E-Rechnungen automatisiert einliest und in die Buchhaltung übergibt, weil ein stiller Ausfall dort erst spät auffallen kann, etwa bei Mahnungen oder verpassten Skontofristen.
• Sie wollen unabhängig von der n8n-Instanz wissen, ob ein zeitkritischer Workflow überhaupt noch läuft: Ein externer Healthcheck-Dienst schließt die Lücke, die der Error-Workflow architektonisch nicht schließen kann.
• Sie hosten n8n selbst und betreiben bereits Prometheus und Grafana: Schalten Sie /metrics mit N8N_METRICS=true und die Ereigniszähler mit N8N_METRICS_INCLUDE_MESSAGE_EVENT_BUS_METRICS=true ein, halten Sie den Endpunkt intern und legen Sie eine Alarmregel auf den Zähler für fehlgeschlagene Workflows. Den Ping pro Workflow ersetzt das nicht, denn übersprungene oder grün beendete Läufe tauchen in diesem Zähler nicht auf.
• Sie haben eigene Prüfkriterien über mehrere Workflows hinweg und die Kapazität, das zu pflegen: Ein Eigenbau-Meta-Workflow bildet das ab – kombiniert mit einem externen Ping, damit der Wächter nicht mit der Instanz zusammen ausfällt.
• Sie wollen Monitoring, Diagnose und Fehlerbehebung nicht selbst aufbauen: Prüfen Sie Managed-Dienste anhand der drei Fragen aus Abschnitt 4 – nicht nur daran, dass „Monitoring“ im Angebot steht. Beauftragen Sie dafür eine Agentur, helfen die Prüffragen vor der Beauftragung.
• Ein Workflow ersetzt eine Bildschirm-Interaktion, weil das Altsystem keine API bietet: Diese Workflows laufen über Browser-Automatisierung und können bei einer Oberflächenänderung falsche oder leere Ergebnisse liefern, ohne dass n8n einen Fehler wirft – eine eingebaute Ergebnisprüfung (die IF-Prüfung aus Abschnitt 1 mit Stop And Error oder /fail-Ping) oder ein eigener Prüf-Workflow ist hier kein Nice-to-have. Welche drei Wege es für Software ohne Schnittstelle überhaupt gibt und wo ihre Grenzen liegen, ordnet unser Beitrag zu Altsystemen ohne API ein.
• Ein Workflow überwacht Vertragsfristen oder andere langlaufende Termine statt einer einzelnen Ausführung: Hier reicht oft ein einfacher Schedule-Trigger mit Fristberechnung und Eskalationsmail – ab wann das nicht mehr trägt und ein dediziertes System nötig wird, zeigt unser Entscheidungswerkzeug zur Vertragsfristen-Überwachung.
• Ein Workflow führt einen wiederkehrenden Bericht aus mehreren Systemen zusammen: Hier reicht die Unterscheidung aus diesem Beitrag nicht aus, denn ein grün beendeter Lauf mit einer leeren Quellantwort erzeugt einen Bericht mit falschen statt fehlenden Zahlen – wie Sie das beim automatisierten Reporting zusätzlich prüfen, ordnet der verlinkte Beitrag ein.

Für den Mittelstand heißt das

Die Wege schließen sich nicht gegenseitig aus – sie schließen unterschiedliche Lücken. Der n8n-eigene Error-Workflow ist in n8n bereits enthalten und braucht keinen weiteren Dienst, deckt aber nur Fehler ab, die n8n selbst erkennt. Ein externer Healthcheck-Dienst ergänzt die Fälle, die der Error-Workflow architektonisch nicht abdecken kann. Wer beides kombiniert, erfährt von Ausführungen, die n8n als fehlgeschlagen protokolliert, vom Totalausfall der Instanz und von zeitgesteuerten Läufen, die n8n übersprungen hat, sofern Zeitraum und Karenzzeit des Checks zum Zeitplan des Workflows passen. Grüne Läufe ohne Daten fängt keiner der beiden von selbst; dafür braucht es eine eingebaute Prüfung mit Stop And Error oder einen /fail-Ping aus dem Leer-Zweig der IF-Prüfung aus Abschnitt 1, alternativ einen Meta-Workflow mit eigener Prüflogik. Ein Eigenbau oder ein Managed-Dienst lohnt sich vor allem, wenn Ihre Workflow-Zahl oder deren geschäftliche Kritikalität wächst.

Klären Sie vor der Tool-Wahl eine Frage: Wer im Unternehmen bekommt die Benachrichtigung, und was passiert in den Minuten danach? Ein Monitoring-Setup, das niemand abarbeitet, schützt nicht: Die Benachrichtigung kommt an, aber niemand reagiert.

Wenn Sie n8n self-hosted betreiben, liegen Betrieb und Überwachung der Instanz bei Ihnen – dafür steht Ihnen dort auch /metrics zur Verfügung, das n8n Cloud laut Doku nicht bietet. Und unabhängig vom gewählten Automatisierungstool – ob n8n, Make oder Power Automate – gilt derselbe Grundsatz: Ein Workflow ohne Überwachung ist kein fertiges Ergebnis, sondern ein unbeobachteter Prozess.

FAQ

Was ist der Unterschied zwischen einem n8n-Error-Workflow und einem Healthcheck-Dienst?

Der Error-Workflow reagiert nur auf Fehler, die n8n selbst erkennt: eine als fehlgeschlagen protokollierte Ausführung oder einen scheiternden Trigger. Ein Healthcheck-Dienst prüft von außen, ob ein erwarteter Ping überhaupt ankommt – und schlägt deshalb auch dann Alarm, wenn die komplette n8n-Instanz ausfällt oder ein Workflow von Hand deaktiviert wurde, also gar keine Fehlermeldung entstehen kann, sofern Zeitraum und Karenzzeit des Checks zum Zeitplan des Workflows passen.

Wie merke ich, dass mein n8n-Workflow grün durchläuft, aber keine Daten liefert?

Der Error-Trigger merkt das grundsätzlich nicht, weil ein leeres Ergebnis für n8n kein Fehler ist. Sie müssen die Prüfung selbst einbauen: eine IF-Node, die prüft, ob das Ergebnis leer ist, und im leeren Zweig eine Stop-And-Error-Node, die die Ausführung aktiv zum Fehler macht. Aktivieren Sie dafür am Node davor die Einstellung „Always Output Data“, denn ohne eingehende Items führt n8n die IF-Node gar nicht aus. Bei leerem Ergebnis kommt dann ein einzelnes leeres Item an; prüfen Sie deshalb, ob ein Pflichtfeld wie die ID fehlt, nicht die Zahl der Items.

Ist healthchecks.io für n8n-Monitoring kostenlos?

Für den Einstieg ja: healthchecks.io bietet neben bezahlten Konten ein kostenloses Konto. Wie viele Checks es erlaubt und was die bezahlten Konten kosten, nennt die Preisseite von healthchecks.io. Weil Healthchecks Open Source ist (BSD-3-Lizenz), können Sie den Dienst auch selbst betreiben, dann aber nicht auf demselben Server wie n8n, sonst fällt der Wächter mit der Instanz aus.

Muss ich für jeden n8n-Workflow einzeln einen Error-Workflow einrichten?

Ja – das Feld „Error Workflow“ ist eine Einstellung pro Workflow, keine instanzweite Voreinstellung. Ein neu angelegter Workflow hat ohne diese Einstellung keine Fehlerbenachrichtigung, sofern er nicht selbst einen Error-Trigger enthält, auch wenn andere Workflows bereits einen Error-Workflow hinterlegt haben.

Was passiert, wenn die komplette n8n-Instanz ausfällt?

Dann feuert kein Error-Workflow mehr, weil er Teil derselben Instanz ist, die ausfällt – und auch ein selbstgebauter Meta-Workflow zur Executions-Prüfung fällt mit aus. Das kann strukturell nur eine Prüfung von außerhalb der Instanz erkennen, etwa ein externer Healthcheck-Dienst, ein Uptime-Monitor, der den /healthz-Endpunkt von n8n abfragt, oder ein Managed-Monitoring-Anbieter.