n8n-Workflows überwachen: kein stiller Ausfall mehr

Eine vergessene manuelle Aufgabe fällt irgendwann auf. Eine ausgefallene Automatisierung dagegen nicht. Bestellungen werden nicht mehr übertragen, Rechnungen nicht mehr erstellt, und das erste Signal kann Tage später von einem Kunden kommen. n8n-Workflows zu überwachen heißt, dafür zu sorgen, dass dieses Signal sofort bei Ihnen ankommt, mit allem, was zur Reparatur nötig ist.

Wir betreiben n8n-Workflows in Produktion, darunter einen Agenten zur Erfassung von Ausgaben über Telegram und den Workflow, der im CRM von Palmora Property, einem Immobilienportal, das wir begleiten, jedem neuen Objekt eine interne Kennung zuweist. Dieser Leitfaden stützt sich auf die Dokumentation von n8n und auf unsere eigenen Vorfälle. Die Wahl des Werkzeugs und der Fall von Software ohne API werden in den anderen Leitfäden unserer Rubrik Automatisierung behandelt.

Kurz gesagt

• Ein einziger Fehler-Workflow, der mit dem Knoten Error Trigger beginnt, kann für alle Ihre Prozesse alarmieren.
• Ein Ausbleibe-Alarm deckt ab, was er nicht sieht: den Prozess, der gar nicht mehr startet.
• Der Verlauf nützt nur, wenn er aufbewahrt wird: Prüfen Sie, was gespeichert wird und wie lange.
• Neu starten ist einfach; keine Duplikate zu erzeugen, wird beim Entwurf vorbereitet.
• Ein Workflow kann mit falschen Daten erfolgreich sein: Kontrollieren Sie auch Mengen und Felder.

Wie wird man informiert, wenn ein n8n-Workflow scheitert?

n8n erlaubt es, für jeden Workflow einen Fehler-Workflow festzulegen, der startet, wenn eine Ausführung scheitert. Laut der Dokumentation zur Fehlerbehandlung muss dieser Workflow mit dem Knoten Error Trigger beginnen, und derselbe kann für mehrere Workflows dienen. Man baut ihn also einmal, sorgfältig:

1. 01Den Fehler-Workflow anlegen.

   Sein erster Knoten ist der Error Trigger. Geben Sie ihm einen klaren Namen (zum Beispiel „Alarme“) und speichern Sie ihn: Er muss nicht veröffentlicht sein, um zu funktionieren.

2. 02Den Alarm anschließen.

   Fügen Sie hinter dem Error Trigger den Versand des Alarms in den Kanal Ihres Teams hinzu.

3. 03Ihn jedem Workflow zuordnen.

   Öffnen Sie in jedem zu überwachenden Workflow die Einstellungen (Settings) und wählen Sie diesen Workflow als Error Workflow.

4. 04Testen.

   Provozieren Sie einen Fehler in einer automatischen Ausführung, um zu prüfen, dass der Alarm wirklich ankommt.

Der vierte Schritt zählt: Laut der Dokumentation des Knotens löst der Error Trigger nur aus, wenn eine automatische Ausführung scheitert, nie bei einem manuellen Start. Für den Test lässt der Knoten Stop And Error eine Ausführung unter den von Ihnen gewählten Bedingungen scheitern.

Was ein guter Alarm enthalten muss:

• den Namen des Prozesses in der Sprache des Fachbereichs („Erstellung der Lieferantenrechnungen“, nicht „Workflow 14“);
• den Schritt, der gescheitert ist, und die Fehlermeldung;
• den Link zur gescheiterten Ausführung, den n8n liefert, wenn die Ausführung gespeichert wird (nicht, wenn der Fehler vom Auslöser selbst kommt);
• was die Person, die den Alarm erhält, tun soll oder wen sie anrufen soll.

Der Kanal zählt ebenso viel wie der Inhalt. Eine E-Mail mehr in einem überfüllten Postfach nützt nichts: Der Alarm muss dort ankommen, wo das Team ohnehin liest, in einem Kanal nur für Alarme, der still bleibt, wenn alles gut läuft. Bei Palmora Property sind das zwei eigene Discord-Kanäle.

Wie weiß man, was verarbeitet wurde und was nicht?

n8n protokolliert die Ausführungen. Die Liste der Ausführungen lässt sich nach Workflow, Status (gescheitert, laufend, erfolgreich, wartend) und Startdatum filtern, und man öffnet dort eine Ausführung, um Schritt für Schritt ihre Daten zu sehen. Vorausgesetzt, sie wurde aufbewahrt, und das wird eingestellt:

• Was gespeichert wird. Laut der Dokumentation von n8n entscheiden die Einstellungen jedes Workflows, ob gescheiterte Produktionsausführungen, erfolgreiche und manuelle Ausführungen aufbewahrt werden. Bewahren Sie die Fehlschläge immer auf. Bewahren Sie auch die Erfolge eines wichtigen Prozesses auf: Sie sind der einzige Beweis, dass eine Verarbeitung stattgefunden hat, wenn jemand fragt, ob die Bestellung vom Dienstag durchgegangen ist.
• Wie lange. Auf einer selbst gehosteten Instanz löscht n8n standardmäßig abgeschlossene Ausführungen, die älter als 14 Tage sind oder über 10 000 Ausführungen hinausgehen, beginnend mit den ältesten, laut seiner Dokumentation zu den Ausführungsdaten. Stellen Sie diese Schwellen nach Ihrem Bedarf ein, ohne zu vergessen, dass der Verlauf Ihre Daten enthält: Namen, Beträge, Adressen.
• Was mit dem Workflow verschwindet. Wer einen Workflow löscht, löscht auch seinen Ausführungsverlauf. Stoppen Sie einen Prozess lieber, statt ihn zu löschen, wenn man Sie dafür zur Rechenschaft ziehen könnte.
• Klar benannte Schritte. Eine Ausführung muss ohne ihren Autor lesbar sein: „Rechnung erstellen“ statt „HTTP Request 3“.

Für einen wichtigen Prozess sollten Sie ein separates Protokoll in Betracht ziehen: eine Zeile pro verarbeitetem Element (die Rechnung X, der Kunde Y) mit ihrem Status, die die Fachperson ohne n8n einsehen kann und die nicht von der Bereinigung des Werkzeugs abhängt.

Wie führt man eine Ausführung ohne Duplikat erneut aus?

Ist die Ursache behoben, bleibt zu verarbeiten, was liegen geblieben ist. Aus der Liste der Ausführungen startet n8n eine gescheiterte Ausführung auf zwei Arten neu: mit dem Workflow, wie er heute gespeichert ist, also korrigiert, oder mit dem ursprünglichen Workflow. Um einen Fehler vor dem Neustart zu verstehen, kopiert die in der Dokumentation beschriebene Funktion Debug in editor die Daten einer vergangenen Ausführung in den Editor, angeheftet an den ersten Knoten (bei Self-Hosting je nach Edition). Die Einstellung Save execution progress erlaubt zudem, dort weiterzumachen, wo die Ausführung stehen geblieben ist, um den Preis etwas höherer Latenz.

Die Falle ist das Duplikat. Hat ein Workflow die Rechnung erstellt und ist dann beim Versand der E-Mail gescheitert, erzeugt ein Neustart von Anfang an eine zweite Rechnung. Die Abhilfe wird beim Entwurf gebaut, nicht während des Ausfalls:

• Jeder schreibende Schritt prüft zuerst, ob das Element bereits existiert, anhand einer Referenzkennung (Bestellnummer, Nummer der Lieferantenrechnung);
• die wichtigste Speicherung kommt vor den Nebenaktionen (Benachrichtigung, E-Mail), nie danach;
• ein gescheitertes Element hält die anderen nicht auf: Bei einem Stapel von fünfzig Rechnungen darf die siebenundvierzigste mit Fehler nicht die drei folgenden blockieren.

Ein Kunde hat die zweite Regel auf die harte Tour gelernt.

Wie erkennt man einen Workflow, der mit falschen Daten erfolgreich ist?

Ein Workflow kann erfolgreich sein und ein falsches Ergebnis liefern: ein leerer Export, „erfolgreich“ verarbeitet, ein auf null gelesener Betrag, weil sich das Format geändert hat, ein PDF, bei dessen Extraktion ein Feld verloren ging. Keiner dieser Fälle löst den Fehler-Workflow aus. Bei Palmora Property würde ohne Schutzmechanismen bei der Veröffentlichung eine leere API-Antwort eine Website mit null Produkten veröffentlichen, bei grün angezeigtem Workflow.

Einige einfache Kontrollen fangen diese Fälle ab:

• eine Mengenschwelle: deutlich weniger Elemente als an einem gewöhnlichen Tag oder gar keine, und nichts wird veröffentlicht, bevor eine Person draufgeschaut hat;
• eine Kontrolle der Löschungen: Eine Verarbeitung, die gleich viel mehr als üblich löschen will, stoppt und warnt;
• Pflichtfelder, die vor dem Schreiben geprüft werden (keine Rechnung ohne Betrag oder Lieferant);
• eine Warteschlange zur menschlichen Prüfung für Zweifelhaftes statt einer automatischen Speicherung.

In n8n verwandelt der Knoten Stop And Error eine gescheiterte Kontrolle in einen echten Fehlschlag:

Diese Kontrollen zählen noch mehr, wenn die Automatisierung über einen Umweg läuft (Export, E-Mail, Bildschirm), wie in unserem Leitfaden, um eine Software ohne API zu automatisieren: Eine Formatänderung auf der Quellseite führt dort schnell zu einem falschen Ergebnis ohne sichtbaren Fehler.

Muss man auch den Server überwachen, auf dem n8n läuft?

Wenn n8n selbst gehostet ist, ja: Der Server gehört zum System. Eine gestoppte Instanz sendet keinen Alarm, da sie nichts mehr tut. Mindestens:

• eine externe Sonde, die woanders als auf dem überwachten Server läuft und prüft, ob die Instanz antwortet;
• die Festplatte: Laut der Dokumentation von n8n kann die Datenbank wachsen, bis der Speicher voll ist; bewahren Sie nichts Unnötiges auf und lassen Sie die Bereinigung aktiv (bei SQLite wird freigegebener Platz nicht automatisch zurückgegeben);
• die Backups und die Updates, deren tatsächliche Schwachstellen wir in unserem Artikel über das Backup eines eigenen Servers beschreiben.

Was prüft man, bevor ein Workflow in Produktion geht?

Ein Workflow, der diese sechs Punkte nicht erfüllt, ist nicht in Produktion: Er ist im Test, und jemand muss das wissen.

Das liefern wir in unserem Angebot: Jeder automatisierte Prozess kommt mit seinen Alarmen und dem Verlauf jeder Ausführung, dazu ein Zähler der Kosten pro Ausführung, und die alte Arbeitsweise bleibt als Rückfallebene bestehen, bis sich die neue bewährt hat. Überwachung und Korrekturen sind mindestens 3 Monate lang enthalten, für 350 € pro Monat, und laufen danach monatlich weiter.

Häufige Fragen

Quellen

1. Der Dokumentation zur Fehlerbehandlung (neuer Tab)docs.n8n.io
2. Liste der Ausführungen (neuer Tab)docs.n8n.io
3. Seiner Dokumentation zu den Ausführungsdaten (neuer Tab)docs.n8n.io