n8n-Fehler, die still bleiben
Der grüne Haken in n8n ist eine Lüge. Er sagt nur: Der Workflow ist durchgelaufen, kein Node hat eine Exception geworfen. Er sagt nicht, dass das getan wurde, was getan werden sollte. Genau diese Lücke hat mich in den letzten Wochen zweimal erwischt – und beide Male war es kein kaputter Workflow, sondern einer, der brav „erfolgreich" meldete.
Der HTTP-Request, der 200 zurückgab – und trotzdem scheiterte
Der erste Fall war ein Webhook, der Daten an eine externe API schickt. Der HTTP-Request-Node bekam eine Antwort mit Status 200. n8n war zufrieden, der Workflow lief weiter, die nächsten Nodes verarbeiteten die Antwort. Nur: Die API hatte in der 200-Antwort ein JSON-Feld "success": false mitgeliefert. Der eigentliche Auftrag war fehlgeschlagen, aber der Statuscode war trotzdem 200, weil der Server die Anfrage ja korrekt entgegengenommen hatte.
Das ist der Klassiker: HTTP-Statuscode ≠ Geschäftserfolg. Ein 200 heißt nur „ich habe deine Anfrage verstanden", nicht „ich habe getan, was du wolltest". Wer nur auf den Statuscode schaut, verarbeitet fröhlich Fehlermeldungen weiter, als wären es Ergebnisse.
Die Lösung war ein IF-Node direkt hinter dem Request, der das Antwort-JSON prüft:
{{ $json.success === true }}Erst wenn das stimmt, geht es weiter. Sonst läuft der Workflow in einen eigenen Fehlerpfad – und der schreibt mir eine Nachricht, statt still zu verschwinden.
Der Node, der einfach nichts fand
Der zweite Fall war subtiler. Ein Workflow liest aus einer Datenbank, filtert nach einem Kriterium und verarbeitet die Treffer. An einem Tag gab es keine Treffer. Kein Fehler, keine Exception – der Filter-Node gab einfach eine leere Liste zurück, und die nachfolgenden Nodes liefen mit null Elementen durch. Der Workflow endete „erfolgreich", nur war eben nichts passiert.
Das ist der zweite Klassiker: leere Ergebnisse sind kein Fehler. n8n unterscheidet nicht zwischen „es gibt nichts zu tun" und „es ist etwas schiefgegangen". Beides sieht für die Engine gleich aus: eine leere Liste.
Hier hilft ein Check auf die Anzahl der Elemente:
{{ $json.length > 0 }}Oder, wenn man mit einem einzelnen Item arbeitet, ein expliziter Check, ob das erwartete Feld überhaupt existiert. Fehlt es, ist das ein Signal – kein Grund, still weiterzumachen.
Was ich daraus mitgenommen habe
Drei Regeln, die ich jetzt bei jedem Workflow anwende, der etwas bewirken soll:
- Nie nur auf den Statuscode vertrauen. Prüfe das Antwort-JSON auf ein Erfolgsfeld, wenn die API eines liefert. Viele APIs tun das – man muss es nur lesen.
- Leere Ergebnisse explizit behandeln. Ein IF-Node mit
length > 0kostet nichts und verhindert, dass ein Workflow „erfolgreich" endet, obwohl er nichts getan hat. - Einen Fehlerpfad bauen, der laut ist. Statt Fehler still zu schlucken, schicke ich mir eine Nachricht. Ein Workflow, der scheitert, darf nicht leise sein – sonst merke ich erst Tage später, dass seit einer Woche nichts mehr angekommen ist.
Der Kern ist simpel: Ein Workflow, der nichts tut, ist schlimmer als einer, der abstürzt. Der Absturz fällt auf. Das stille Nichts nicht.
Und genau deshalb ist der grüne Haken in n8n nur die halbe Wahrheit. Er bestätigt, dass der Code lief. Ob er das Richtige getan hat, muss ich selbst prüfen – mit einem IF-Node mehr und einem Fehlerpfad, der sich meldet.