Finde n8n-Workflows, die nicht mehr laufen

Eine fehlgeschlagene Ausführung ist der einfache Fall: Sie steht in der Ausführungsliste, und ein Error-Workflow kann sie melden. Teuer wird der Workflow, der weiter als aktiv gilt und einfach nie gelaufen ist – nach einem Neustart, der den Schedule-Trigger nicht neu registriert hat, oder weil jemand ihn beim Debuggen abgeschaltet hat. Es gibt keinen Fehler, weil nichts passiert ist.

Das hier ist ein kostenloser n8n-Workflow, der genau das findet. Er liest deine eigene Instanz über die n8n-API, holt für jeden Workflow, der sich selbst startet, den letzten Lauf und vergleicht ihn mit dessen eigenem Zeitplan: still heißt doppeltes Intervall plus fünf Minuten ohne Lauf. Webhook- und Formular-Workflows lässt er in Ruhe, denn Leerlauf ist bei ihnen normal. Importieren, ein Feld setzen, deinen Meldeknoten anhängen.

1. Step 1

   In n8n unter Einstellungen → n8n API einen API-Schlüssel anlegen.

2. Step 2

   Am Knoten „Get workflows“ eine Header-Auth-Zugangsdatei anlegen, mit dem Namen X-N8N-API-KEY und deinem Schlüssel als Wert. Dieselbe Zugangsdatei am Knoten „Get last run“ noch einmal auswählen.

3. Step 3

   Im Knoten „Configuration“ deine n8n-Adresse eintragen. Danach hinter „Find silent workflows“ anhängen, womit du sonst Meldungen verschickst. Er liefert ein einzelnes Element mit einer Anzahl und einer fertigen Zusammenfassung.

4. Step 4

   Optional, und die Minute wert: die Ping-Adresse eines Dead-Man's-Switch-Dienstes wie healthchecks.io in heartbeatUrl eintragen. Der Workflow pingt sie bei jedem Lauf. Bleiben die Pings aus, meldet sich der Dienst.

Was er nicht kann

Dieser Workflow lebt in der Instanz, die er überwacht. Ist sie ausgefallen, mitten im Neustart, oder haben sich ihre Zeitplan-Auslöser nie neu registriert, läuft auch die Prüfung nicht – und für sich genommen sieht ihr Schweigen genauso aus, als wäre alles in Ordnung. Der Heartbeat macht aus diesem Schweigen eine Meldung, aber nur das: Er sagt dir, dass die Prüfung stehen geblieben ist, nicht welcher deiner Workflows.

Manche Workflows lassen sich aus der Ausführungshistorie nicht beurteilen, und er sagt das, statt zu raten: Zeitpläne ohne festes Intervall, Workflows, die erfolgreiche Ausführungen nicht speichern, und seltene Zeitpläne, deren letzten Lauf n8n womöglich schon gelöscht hat. Sie kommen mit Begründung unter notCovered zurück. Wirkt die Hälfte der geprüften Workflows oder mehr gleichzeitig still, markiert er sein eigenes Ergebnis als zweifelhaft: Das ist entweder ein echter Massenstillstand nach einem Neustart oder eine Prüfung, die nicht sieht, was sie braucht.

Er beurteilt Zeitpläne, nicht Arbeit: Ein Workflow, der pünktlich läuft und nichts erzeugt, sieht für ihn gesund aus.

Warum ein Error-Workflow das nicht abdeckt: der Vergleich im Detail.

Der Rest der Liste

Stehengebliebene Zeitpläne sind einer von sieben Ausfällen, die keine Fehlermeldung erzeugen. Die anderen sind Rate-Limits, abgelaufene Zugangsdaten, Webhooks, die niemand mehr aufruft, gelöschte Ausführungshistorie und die Sommerzeit. Die Checkliste hat alle sieben, mit der einen Prüfung, die jeden davon findet. Oder lass Duskwatch sie von außen laufen – über alle Kundeninstanzen, die du betreust.

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.