Was Duskwatch prüft, speichert und verschickt

Die Zahlen unten stehen so im laufenden Code, es sind keine gerundeten Beschreibungen. Weicht hier etwas von dem ab, was du siehst, ist das ein meldenswerter Fehler.

Die drei Prüfungen

Jede verbundene Instanz wird einmal pro Minute abgefragt. Jeder Durchgang liest die Workflow-Liste und die jüngsten 200 Ausführungen über die öffentliche n8n-API und wertet daraus drei Dinge aus.

1. Fehlgeschlagene Ausführungen. Jede Ausführung, die n8n als fehlgeschlagen meldet, wird einmal zum Vorfall. Der erste Durchgang nach dem Verbinden übernimmt die vorhandene Historie, ohne zu melden – sonst erzeugte eine Instanz mit einem Monat Fehlern dahinter eine Flut. Bis zu 20 Fehler je Durchgang werden um den fehlerhaften Knoten und eine gekürzte Meldung ergänzt; der Rest wird trotzdem erfasst, nur ohne dieses Detail.

2. Workflows, die nicht mehr laufen. Für jeden aktiven Workflow wird das erwartete Intervall aus seinem eigenen Schedule-Trigger abgeleitet, du stellst also keine Schwelle je Workflow ein. Als stehengeblieben gilt er, wenn das doppelte Intervall plus fünf Minuten ohne Ausführung vergangen ist, frühestens aber nach zehn Minuten. Das Intervall lässt sich je Workflow überschreiben oder abschalten. Der Vorfall schließt sich von selbst, sobald der Workflow wieder läuft, deaktiviert wird oder aus n8n verschwindet.

3. Instanzen, die nicht mehr antworten. Eine einzelne fehlgeschlagene Anfrage ist kein Ausfall, sondern ein Paket. Als nicht erreichbar gilt eine Instanz nach zwei fehlgeschlagenen Durchgängen in Folge, und der Abstand wächst nach jedem Fehlschlag, damit eine kränkelnde Instanz nicht zusätzlich bedrängt wird. Der Vorfall schließt sich beim nächsten erfolgreichen Durchgang. Eine Anfrage bekommt höchstens 45 Sekunden.

Ein viertes Signal, und was es wert ist

Ein Workflow kann pünktlich laufen, Erfolg melden und nichts tun. Keine der drei Prüfungen oben sieht das, weil nichts fehlgeschlagen ist und nichts fehlt. Die einzige von außen sichtbare Spur ist die Dauer: Ein Lauf, der 400 Datensätze verarbeitet, dauert länger als einer, der keinen verarbeitet.

Ist die mittlere Laufdauer eines Workflows in den letzten zwei Tagen mindestens fünfmal kürzer als in den vierzehn Tagen davor, wird das gemeldet. Schutz gegen Rauschen: mindestens 20 Läufe Historie, mindestens 5 frische Läufe, und ein früherer Mittelwert über zwei Sekunden – darunter misst man Netzschwankung statt Arbeit. Das ist kein Beweis, dass der Workflow nichts tut. Es ist ein Grund hinzusehen, und die Meldung sagt das auch.

Am besten funktioniert das dort, wo die Zeit in Datenbewegung steckt. Wo ein Lauf größtenteils auf ein Modell oder einen anderen langsamen Aufruf wartet, ist ein leerer Lauf nur etwas schneller: Ein Praktiker hat denselben Agenten mit zehn Datensätzen bei 18,8 Sekunden gemessen und ohne Datensatz bei 13,2 Sekunden, rund 30 Prozent. Für diesen Fall gibt es eine zweite Regel. War der Tagesdurchschnitt eines Workflows in den Wochen davor gleichmäßig, wird auch ein Einbruch um mindestens ein Viertel gemeldet, wenn er mehr als drei Standardabweichungen unter dem gewohnten Niveau liegt. Das erkennt den Agenten-Fall, solange seine Läufe gleichmäßig sind. Ein Einbruch innerhalb der gewohnten Tag-zu-Tag-Schwankung fällt weiterhin nicht auf, und bei Agenten mit unruhigen Laufzeiten bleibt das Mitzählen an den Rändern des Workflows das bessere Werkzeug.

Was der API-Schlüssel können muss

Ein n8n-API-Schlüssel mit Leserecht auf Workflows und Ausführungen. Duskwatch schreibt nie in deine Instanz: Es aktiviert nichts, deaktiviert nichts, wiederholt nichts und löscht nichts. Schlüssel werden vor dem Speichern mit AES-256-GCM verschlüsselt, und mit der Instanz wird auch der Schlüssel gelöscht. Ein Widerruf in n8n beendet die Verbindung sofort von deiner Seite.

Instanzadressen müssen öffentliches HTTPS sein. Private und Link-Local-Adressbereiche werden abgewiesen, ebenso Adressen mit Zugangsdaten, Abfrageteil oder Anker, und Weiterleitungen werden nicht verfolgt. Eine nicht öffentliche Instanz kann der Betreiber freigeben; das existiert für unseren eigenen Testaufbau, nicht als Funktion.

Was gespeichert wird

Workflow-Name und -ID, Ausführungs-ID, Zeitstempel, der Name des fehlerhaften Knotens und eine bei 500 Zeichen gekürzte Fehlermeldung. Tageszahlen je Workflow: Erfolge, Fehler und Gesamtlaufzeit. Das ist die ganze Liste.

Nie der Inhalt der Ausführung. Die Daten, die durch die Workflows deiner Kunden fließen, werden nicht gelesen, nicht angefordert und nicht gespeichert – deshalb sind inhaltliche Prüfungen auch nicht Teil des Leistungsumfangs. Es gibt eine Vereinbarung zur Auftragsverarbeitung für diesen Teil des Gesprächs mit deinem Kunden.

Meldungen

Meldungen gehen an die Alarmadresse der Agentur, dazu an jeden Slack- oder Telegram-Kanal, den du einrichtest. Offene Vorfälle werden zu einer Nachricht gebündelt statt einzeln verschickt, und es gilt eine Ruhezeit von standardmäßig 15 Minuten je Instanz, die du ändern kannst. Ein Vorfall, der sich vor dem Versand erledigt hat, fällt aus der Nachricht heraus – in der Übersicht bleibt er sichtbar.

Grenzen, die man kennen sollte

Das Ausführungsfenster umfasst die jüngsten 200 Läufe je Durchgang. Auf einer sehr betriebsamen Instanz kann zwischen zwei Durchgängen etwas aus diesem Fenster fallen; das Protokoll sagt es, wenn das Fenster voll zurückkommt. Davon unabhängig räumt n8n seine eigene Ausführungshistorie nach einem Zeitplan weg, den du über EXECUTIONS_DATA_MAX_AGE steuerst – was vor unserer Abfrage gelöscht wurde, ist endgültig weg. Auch deshalb laufen die Tageszahlen außerhalb deiner Instanz mit.

Duskwatch meldet und repariert nicht. Es startet keinen Workflow neu, schaltet keinen Trigger scharf und wiederholt keine Ausführung, und das ist auch nicht geplant.

Wenn das Verbinden fehlschlägt

Die Meldung nennt die Ursache. HTTP 401 heißt, der Schlüssel wurde abgelehnt. 403 heißt, dem Schlüssel fehlt das Recht für diese Route. 404 heißt meistens, dass die öffentliche API nicht aktiviert ist – in manchen n8n-Aufbauten ist sie standardmäßig aus. Ein 400 auf der Ausführungsliste deutet auf ein älteres n8n, dessen API einen der Statusfilter ablehnt; dieser Fall ist abgefangen, eine Version, die alle ablehnt, lässt sich aber gar nicht lesen. Ein Zeitlimit nennt die Route, auf der es aufgetreten ist.

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.