Inhalt
Ein n8n-Workflow kann mit einer grünen Success-Meldung enden, obwohl die erwartete Aktion nie stattgefunden hat. Eine Bestellung bleibt auf processing, ein Beitrag wird nicht veröffentlicht, ein Datensatz fehlt, und in der Execution-Liste steht trotzdem „Success“.
Das ist kein Widerspruch. Eine grüne Execution besagt in der Regel, dass kein Node einen Fehler ausgelöst hat. Ob auch das eingetreten ist, was der Workflow erreichen sollte, zeigt sie dir nicht. Bei kritischen Workflows musst du das gesondert prüfen. Dieser Artikel zeigt, wie.
Technischer Erfolg und fachliches Ergebnis
Wir unterscheiden in diesem Artikel zwei Dinge (englisch: Execution Success und Outcome Success). Das sind Begriffe dieses Artikels, keine offiziellen n8n-Statusbezeichnungen:
- Technischer Erfolg: Die Execution wurde beendet, ohne dass ein Fehler sie abgebrochen hat.
- Fachliches Ergebnis: Das, was der Workflow tatsächlich bewirken sollte.
Ein Beispiel: Ein Workflow soll eine Bestellung verarbeiten und ihren Status auf completed setzen. Die Execution kann grün enden, obwohl
- ein Filter keine Items weitergibt,
- nachgelagerte Nodes deshalb keine Daten erhalten,
- die erwartete Datenbankänderung ausbleibt,
- oder ein Ergebnis zwar vorliegt, aber nicht die erwarteten Werte enthält.
Wie n8n Executions zählt und was sie kosten, erklärt n8n Executions berechnen.
Zwei Beispiele aus der n8n Community
Das Muster ist nicht theoretisch.
Beispiel 1: In dem Thread „Successfully but Actually Do Nothing“ beschreibt ein Nutzer einen Workflow aus Webhook, Validierung, PostgreSQL-Abfrage, HTTP Request und Status-Update. Die Execution ist grün, doch gelegentlich bleibt die erwartete Aktion aus. Entweder wird der HTTP Request übersprungen, weil eine vorherige Bedingung keine Items weitergibt, oder das Datenbank-Update betrifft null Zeilen. Einen Node-Fehler gibt es dabei nicht. Der Autor überlegt, das Ergebnis des Updates ausdrücklich zu prüfen.
Kommt dagegen gar keine Execution zustande, weil der Webhook nicht erreichbar ist, liegt ein anderes Problem vor: n8n Webhook 404 und dynamische Pfade.
Beispiel 2: In dem Thread „Social Media Autoposter – Workflow Shows Success But Posts Not Publishing“ schildert ein Nutzer 183 erfolgreiche Ausführungen, ohne dass ein einziger geplanter Social-Media-Post veröffentlicht wurde. Die Datensätze blieben in seiner Datenbank auf Scheduled.
Antwortende vermuten, dass weiter oben im Workflow keine Items mehr ankamen und die nachfolgenden Nodes deshalb nicht ausgeführt wurden. Eine bestätigte Ursache nennt der Thread nicht. Für diesen Artikel zählt etwas anderes: Ein Workflow, dessen Zweck das Veröffentlichen ist, kann beliebig oft grün durchlaufen, ohne zu veröffentlichen.
Wann 0 Items korrekt sind und wann nicht
Ein häufiger Auslöser ist ein Node, der keine Items an den nächsten Schritt übergibt:
Trigger
↓
Daten abrufen
↓
Filter
↓
HTTP Request
↓
Ergebnis speichern
Lässt der Filter nichts durch, erhält der Rest dieses Pfades keine Daten. Nach der Beschreibung in den Community-Threads werden die nachfolgenden Nodes dann in der Regel gar nicht ausgeführt, und zwar ohne Fehlermeldung. Je nach Einstellungen der Nodes kann das im Einzelfall anders aussehen.
Ein leeres Ergebnis ist deshalb nicht von vornherein ein Problem. Es ist völlig korrekt, wenn
- es keine neuen Datensätze gibt,
- keine Bestellung die Suchbedingung erfüllt,
- keine Nachricht verarbeitet werden muss,
- oder ein Filter bewusst alles ausschließt.
Wer jede leere Ausgabe als Fehler behandelt, erzeugt Fehlalarme. Die richtige Frage lautet:
Ist „0 Items“ in diesem konkreten Workflow-Zustand das erwartete Ergebnis?
Problematisch wird es, wenn der Workflow ein Ergebnis erwartet und es ausbleibt.
Das erwartete Ergebnis festlegen
Bevor du prüfen kannst, musst du festlegen, was nach einem kritischen Schritt gelten soll. Je nach Workflow kann das heißen:
- mindestens ein Item liegt vor,
- ein bestimmtes Feld ist vorhanden,
- ein Status hat einen bestimmten Wert,
- eine Datenbankänderung hat tatsächlich eine Zeile betroffen,
- eine API-Antwort enthält den erwarteten Inhalt (zum Aufbau von API-Aufrufen siehe n8n HTTP Request).
Die Prüfung sollte direkt nach der kritischen Aktion stehen, nicht erst am Ende des Workflows. So siehst du, an welcher Stelle das Ergebnis verloren ging.
Beispiel: Ergebnis mit einem IF-Node prüfen
Aktion
↓
Ergebnis prüfen (IF)
├── erwartetes Ergebnis → weiter
└── unerwartetes Ergebnis → Stop And Error
Angenommen, ein vorheriger Schritt liefert:
{
"resultCount": 1,
"status": "new",
"amount": 100
}
Der IF-Node prüft dann beispielsweise:
resultCount > 0
AND status = "new"
AND amount > 0
Das ist nur ein Beispiel. Welche Felder und Bedingungen sinnvoll sind, hängt von deinem Anwendungsfall ab. Entscheidend ist, dass du das erwartete Ergebnis ausdrücklich definierst, statt pauschal „0 Items = Fehler“ zu setzen.
Stop And Error: ein unerwartetes Ergebnis zum Fehler machen
Mit dem Stop And Error-Node kannst du eine Execution unter von dir definierten Bedingungen bewusst fehlschlagen lassen. Du kannst eine eigene Fehlermeldung oder ein Fehlerobjekt mitgeben. Im Fehlerzweig des IF-Nodes sieht das so aus:
Erwartet: mindestens eine aktualisierte Bestellung.
Ergebnis: 0.
Damit wird aus einem still akzeptierten Zustand ein echter Fehlerzustand der Execution. Für kritische Schritte ist das sinnvoll, bei denen „grün“ allein nicht genügt.
Error Workflow: was er leistet und was nicht
Der Error Trigger startet einen Error Workflow, wenn ein verknüpfter Workflow fehlschlägt. Dafür legst du einen eigenen Workflow mit dem Error Trigger als erstem Node an und wählst ihn in den Workflow Settings des überwachten Workflows als Error Workflow aus. Die Einrichtung ist in Error Workflows beschrieben.
Der Error Workflow reagiert auf Fehler, er prüft keine Ergebnisse. Endet ein Workflow technisch erfolgreich, aber fachlich falsch, entsteht kein Fehler, auf den er reagieren könnte. Erst die Kombination schließt die Lücke:
Kritischer Schritt
↓
Ergebnis prüfen (IF)
├── OK → weiter
└── unerwartet → Stop And Error → Error Workflow
Die n8n-Dokumentation nennt Stop And Error ausdrücklich als Weg, Fehler gezielt an den Error Trigger zu schicken.
Wichtig beim Testen
Laut Dokumentation läuft der Error Trigger nur, wenn ein automatisch ausgeführter Workflow fehlschlägt. Ein manueller Lauf im Editor zeigt dir deshalb nicht, ob die automatische Fehlerkette funktioniert. Dafür brauchst du eine automatisch ausgelöste Execution.
PostgreSQL: Änderung prüfen
Bei Datenbankänderungen kannst du in PostgreSQL mit RETURNING arbeiten. Das folgende Beispiel stammt aus dem ersten Community-Thread:
UPDATE orders
SET status = 'completed'
WHERE id = $1
AND status = 'processing'
RETURNING id;
Das ist ein PostgreSQL-Beispiel, keine allgemeine Regel für andere Datenbanken oder andere n8n-Nodes, und auch nicht der einzige Weg.
Der Haken: Betrifft das Update keine Zeile, kommt auch kein Item zurück. Ein IF dahinter hat dann womöglich nichts, was er prüfen könnte. Eine Antwort im Thread löst das, indem die Abfrage immer genau ein Item mit einem Zähler liefert:
WITH changed AS (
UPDATE orders
SET status = 'completed'
WHERE id = $1
AND status = 'processing'
RETURNING id
)
SELECT COUNT(*)::int AS updated
FROM changed;
Ein IF-Node prüft danach, ob updated den erwarteten Wert hat (in diesem Beispiel 1). Im Fehlerzweig steht Stop And Error. Dieselbe Antwort empfiehlt außerdem, abgewiesene Items bei vorgelagerten Prüfungen über den false-Zweig eines IF zu leiten, statt sie fallen zu lassen. Eine Prüfung am Ende kann kein Item erkennen, das sie nie erreicht hat.
Checkliste und Entscheidungsregel
Wenn ein Workflow grün ist, das Ergebnis aber fehlt:
- Erwartung klären: Was sollte nach dem Lauf passiert sein?
- Item-Zahlen ansehen: Öffne eine abgeschlossene Execution (Übersicht: All Executions) und lies die Item-Anzahl Node für Node von links nach rechts. Der erste Node ohne Output-Items zeigt, wo das Ergebnis verloren ging. Das ist der Vorgehensweg aus dem zweiten Community-Thread.
- Inhalt prüfen: Ein Item kann vorhanden und trotzdem falsch sein, etwa mit falschem Status oder Betrag.
- Entscheiden: Siehe unten.
| Situation | Entscheidung |
|---|---|
| Ergebnis wie erwartet | Workflow läuft weiter. |
| Leeres Ergebnis, unter diesen Bedingungen normal | Kein Fehler. |
| Ergebnis weicht ab | Ursache suchen, vorgelagerte Nodes prüfen. |
| Abweichung ist bei einem kritischen Schritt nicht akzeptabel | Per IF erkennen und mit Stop And Error bewusst fehlschlagen lassen. |
Ob ein AI Agent oder ein klassischer Workflow für dein Vorhaben passt, ist eine eigene Entscheidung: n8n AI Agent. Wo du n8n betreibst, behandelt n8n Cloud oder Self-Hosted.
Fazit
Ein grüner n8n-Workflow bestätigt den technischen Ablauf. Ob das erwartete fachliche Ergebnis eingetreten ist, musst du bei kritischen Workflows separat prüfen: Lege fest, was erwartet wird, prüfe es direkt nach dem Schritt und lass nicht akzeptable Abweichungen bewusst als Fehler enden.
Quellen und weiterführende Artikel
n8n Community
- Successfully but Actually Do Nothing
- Social Media Autoposter – Workflow Shows Success But Posts Not Publishing
n8n-Dokumentation
RELVRO
