Error-Workflow gegen externes Monitoring
Der Error-Workflow ist die eingebaute Antwort, er kostet nichts, und für eine Art von Problem ist er das richtige Werkzeug. Es lohnt sich, genau zu sein, welche Art das ist – denn der Unterschied ist keine Frage des Grades: Es gibt Ausfälle, die ein Error-Workflow strukturell nicht sehen kann.
Was der Error-Workflow gut kann
Wenn eine Ausführung läuft und einen Fehler wirft, übergibt n8n dem Error-Workflow den Namen des Workflows, den fehlerhaften Knoten und die Fehlermeldung. Je Workflow eingerichtet oder als Standard der Instanz macht das aus einem stillen Eintrag in der Ausführungsliste eine Nachricht, die dich wirklich erreicht. Für eine einzelne Instanz, in die du täglich schaust, reicht das oft.
Die zwei Dinge, die er nicht kann
Er feuert nur, wenn etwas läuft. Ein Schedule-Trigger, der sich nach einem Neustart nie neu registriert hat, erzeugt keine Ausführung, also keinen Fehler, also keine Meldung. Der Workflow steht weiter auf aktiv, die Instanz sieht gesund aus. Nichts unterscheidet das von einer wirklich ruhigen Woche – außer dem Vergleich des letzten Laufs mit dem Intervall, in dem der Workflow laufen sollte.
Und er stirbt mit der Instanz. Ist n8n aus, ohne Speicher oder mitten im Neustart, ist der Error-Workflow ebenfalls aus. Genau in dem Moment, in dem du eine Nachricht am dringendsten brauchst, kann sie niemand mehr verschicken. Ein Wächter außerhalb der Instanz bemerkt den Ausfall beim nächsten Durchgang – gerade weil er nicht davon abhängt, dass die Instanz noch lebt.
| Ausfall | Error-Workflow | Von außen überwacht |
|---|---|---|
| Ausführung lief und schlug fehl | Ja, mit Knoten und Meldung | Ja, beim nächsten Durchgang |
| Workflow läuft nicht mehr | Nein – nichts lief, also feuerte nichts | Ja, letzter Lauf gegen erwartetes Intervall |
| Instanz nicht erreichbar | Nein – er ist selbst mit aus | Ja, genau dafür ist er da |
| Mehrere Kundeninstanzen auf einmal | Eine Einrichtung je Instanz, keine gemeinsame Sicht | Eine Liste über alle hinweg |
| Nachweis für den Kunden im Nachhinein | Nur, was noch in der Ausführungsliste steht | Außerhalb der Instanz aufbewahrt |
Es sind keine Alternativen
Behalte den Error-Workflow. Er liefert dir den fehlerhaften Knoten und die Meldung, und das sieht kein Beobachter von außen so genau. Ergänze die Außensicht für die zwei Fälle, die er nicht erreicht: den Lauf, den es nie gab, und die Instanz, die nicht mehr antwortet. Bei einer Instanz kannst du den Außenteil von Hand machen – der kostenlose Workflow übernimmt die Stillstandsprüfung, lebt aber selbst in der Instanz und erbt damit deren Grenze. Über mehrere Kundeninstanzen hinweg trägt die Handarbeit nicht mehr – und da kommt Duskwatch ins Spiel.
Duskwatch beobachtet die n8n-Instanzen, die du für Kunden betreibst, von außen und meldet die Ausfälle, die keinen Fehler erzeugen: den Lauf, den es nie gab, und die Instanz, die nicht mehr antwortet.