Ich muss Workflows besser überwachen.
Wie macht ihr das?
@patriciaLee die native Antwort, die die meisten Leute übersehen, ist der Error Workflow – stell einen global in den Einstellungen ein und er wird bei jeder fehlgeschlagenen Ausführung ausgelöst, sodass du den Fehler in Slack/E-Mail/wohin auch immer pushen kannst, ohne etwas abzufragen. Zum Durchsuchen/Prüfen gibt es die Executions-Ansicht mit Status-Filtern. Und wenn du selbstgehostet bist, setze N8N_METRICS=true, um einen Prometheus-Endpoint unter /metrics freizugeben, den du in Grafana abgreifen kannst für Dashboards und Alerting. Error Workflow + Metrics deckt die meisten Production-Setups ab.
Es gibt zwei Kategorien, die ich bewerte. Die erste Kategorie ist die Ausführungsintegrität. Ich möchte wissen, ob die Ausführung gestartet wurde, beendet wurde oder auf einen Fehler gestoßen ist. Die andere Kategorie ist das Geschäftsergebnis. Ich muss feststellen, ob die Ausführung das getan hat, was sie tun sollte. Diese Kategorie ist schwieriger zu bewerten. Wenn beispielsweise eine Ausführung dazu führt, dass ein Filter alle Datensätze überspringt, wäre die Ausführung erfolgreich, aber völlig nutzlos.
Wenn ein Workflow wichtig genug ist, erfasse ich weitere Einzelheiten, einschließlich der Anzahl der verarbeiteten Datensätze, des endgültigen Status des Workflows, des Grundes für den Fehler des Workflows, des Eigentümers des Workflows und des vorgeschlagenen nächsten Schritts.
Zusätzlich zu Fehlern überwache ich einige andere Symptome. Wenn Workflows nicht erfolgreich abgeschlossen wurden, wenn die Anzahl der verarbeiteten Datensätze auf 0 fällt oder wenn die Anzahl der Wiederholungsversuche zunimmt, gebe ich eine Warnung aus. Ich bemühe mich immer, Warnungen umsetzbar zu gestalten.
@patriciaLee achamm hat die Kernpunkte abgedeckt (Error Workflow + Executions view + Prometheus/Grafana) — das ist die richtige Grundlage. Zwei Dinge würde ich noch hinzufügen, die fangen, was diese übersehen:
- Mache den Error Workflow tatsächlich handlungsfähig. Eine bloße „ein Workflow ist fehlgeschlagen
Guter Punkt von @ShawnWilliams zur Unterscheidung Ausführungsintegrität vs. Geschäftsergebnis. Ein Beispiel aus der zweiten Kategorie das vielleicht hilft: Ich habe einen täglichen Workflow gebaut der nicht auf Fehler überwacht, sondern auf Content-Möglichkeiten, er durchsucht Foren-Posts und bewertet via LLM ob sie für mich relevant sind, dann schickt er eine Zusammenfassung per Mail.
Der Punkt ist: “Monitoring” muss nicht nur Fehler bedeuten. Du kannst denselben Error-Workflow-Mechanismus nutzen um auch positive Trigger zu erkennen, sei es neue Leads, Inhalte, oder eben offene Fragen die du beantworten kannst. Die technische Basis (achamms Setup) bleibt gleich, nur die Bedingung die den Alert auslöst ändert sich von “Fehler aufgetreten” zu “interessantes Ereignis erkannt”.
@patriciaLee und andere haben die Kernaspekte abgedeckt (Error Workflow, Executions-Ansicht, Prometheus/Grafana und die Unterscheidung zwischen Execution Health und Business Outcomes). Ich würde eine weitere Ebene hinzufügen, die mir in der Produktion Probleme bereitet hat: stille Fehler.
Error Workflows und Metriken helfen nur, wenn etwas tatsächlich ausgeführt wird und einen Fehler wirft. Sie erfassen keinen Trigger, der nicht mehr ausgelöst wird, kein Webhook-Abonnement, das still abläuft (Gmail Watches sind ein klassisches Beispiel), und keinen Cron-Job, der nie läuft. Nichts wird ausgeführt, also wird nichts beobachtet. Nach meiner Erfahrung sind das oft die schmerzhaftesten Fehler, weil man sie von einem Kunden erfährt und nicht vom Monitoring.
Der Ansatz, auf den ich mich geeinigt habe, ist ein Dead-Man’s Switch: Ein geplanter Workflow pingt einen Heartbeat-Service (Healthchecks.io, Better Stack oder selbst gehostete Uptime Kuma). Wenn der Heartbeat nicht mehr ankommt, das ist der Alert. Er ergänzt Error Workflows, indem er „es läuft überhaupt nicht mehr
Shawns Aufteilung würde ich verwenden: Ausführungsintegrität vs. Geschäftsergebnis.
Für Client-Workflows würde ich der Benachrichtigung eine kleine Ausführungsquittung hinzufügen: erwartetes Zeitfenster, berührte Datensätze, verwendetes Konto/Anmeldedaten, versuchte nachgelagerte Aktion, endgültige Datensatz-/Nachrichten-ID und wer für den nächsten Schritt verantwortlich ist. Die grüne Ausführung ist weniger nützlich als ein Nachweis darüber, was sich geändert hat.
Dieser Thread behandelt bereits die wichtige Unterteilung gut – Ausführungs-Health versus ob das Ergebnis tatsächlich eingetreten ist – plus die Heartbeat-Idee für den Run, der niemals auslöst. Daher werde ich nur den einen Fehler hinzufügen, der immer noch an all dem vorbeikommt. Auch mit einer Record-Count-Prüfung und einem Dead-Man-Switch an Ort und Stelle ist der Fall, der die Leute erwischt, der Run, der abgeschlossen wird, seine übliche Anzahl von Zeilen verarbeitet, nichts auslöst und trotzdem falsch ist, weil ein Credential stillschweigend abgelaufen ist oder eine Quelle veraltet ist und die API eine gültige, aber leere oder Platzhalter-Response zurückgegeben hat. Die Anzahl sieht normal aus, der Status ist grün, nichts wirft einen Fehler, also flaggt keine der Schichten darüber es.
Der Grund, warum ein Standard-Error-Trigger blind für dies ist: Es gab keinen Fehler. Das Token ist nicht laut fehlgeschlagen, es hat saubere 200 mit nichts Nützlichem darin zurückgegeben, und der Workflow hat das glücklich weitergeleitet. Ein Record-Count-Alert übersieht es auch, weil die Anzahl normal sein kann, während der Inhalt veraltet oder leer ist.
Was es ohne großen Aufwand fängt, ist die Prüfung des Inhalts, nicht nur der Anwesenheit. Nach jedem auth-sensitiven Call sollte man auf ein Feld zusichern, das nur auftaucht, wenn der Call wirklich funktioniert hat, anstatt nur zu prüfen, dass die Response nicht leer ist, und einen Freshness-Check hinzufügen – ist der neueste Record wirklich aktuell, oder schaue ich mir Daten von gestern an, die mir zurückgegeben werden. Speziell beim Credential-Aspekt hilft es, ein unerwartetes leeres Ergebnis von einer normalerweise beschäftigten Quelle als Fehlerzustand statt als stilles Erfolg zu behandeln.
Die Mentalität, die den ganzen Thread zusammenhält: ein grüner Run mit einer normalen Zeilenanzahl ist immer noch kein Beweis, dass die Daten echt sind, sondern nur, dass etwas zurückkam. Die Prüfung, die es wert ist, hinzugefügt zu werden, ist, ob das Ergebnis aktuell und korrekt ist, nicht nur vorhanden. Was macht ihr gegen den veralteten-aber-grünen Fall, oder hat er euch noch nicht getroffen?
Dieser Thread deckt die Kernebenen gut ab: Error-Workflow mit Kontext, Prometheus/Grafana, Heartbeat für stille Ausfälle und den Green-but-Stale-Fall, den jemand angesprochen hat. Eine Lücke, die ich hinzufügen würde, besonders wenn du n8n nicht isoliert betreibst:
Alles bisher Erwähnte ist n8n-native. Error Workflow, N8N_METRICS, die Executions-Ansicht. Das ist die richtige Entscheidung, wenn n8n deine einzige Automation-Oberfläche ist. Aber viele Teams sind nicht rein n8n-basiert. Sie haben Make-Szenarien, ein paar Zapier-Zaps, einen Cron-Job, vielleicht ein oder zwei Skripte, die alle echte Produktionsarbeit verrichten. Jedes hat sein eigenes Dashboard, also “ist alles gesund” bedeutet, drei oder vier verschiedene Orte zu überprüfen, und das Heartbeat-Pattern, das die Leute hier beschrieben haben, muss für jedes Tool separat neu aufgebaut werden.
Das Pattern, das für mich funktioniert hat: Behandle “hat es gelaufen, hat es funktioniert, ist es fehlgeschlagen” als ein einfaches Event, das du von überall dort auslöst, wo die Automation lebt. Ein HTTP-Call aus n8ns Success- und Error-Pfaden, das gleiche von einem Make-Webhook oder Zapier-Webhook oder einem Try/Except in einem Skript, alle landen an einem Ort, der nicht kümmert, welches Tool es gesendet hat. Die gleiche Heartbeat-Idee wie oben, nur nicht an eine Plattform gebunden.
Haftungsausschluss, da ich es direkt sagen sollte: Ich habe ein Tool genau für das gebaut (FlowPulse), nachdem ich auf das gleiche Problem “vier Dashboards, keine einzige Ansicht” selbst gestoßen bin. Ich versuche nicht, einen Pitch mitten in einen guten Thread zu werfen, nur um die Flagge zu setzen, dass es da ist, falls die Cross-Platform-Komponente für jemanden nützlich ist. Ich helfe auch gerne, die DIY-Version zu durchlaufen, wenn dir das mehr zusagt.