n8n-Workflow-Fehler systematisch finden statt raten

Einen n8n-Workflow-Fehler findest du systematisch, indem du die Daten des betroffenen Laufs in den Editor lädst und Knoten für Knoten vergleichst, bis die tatsächliche Ausgabe zum ersten Mal von der erwarteten abweicht — an genau diesem Knoten liegt die Ursache. Der Knoten, an dem der Workflow sichtbar falsch endet, ist dabei oft nicht der Ort des Fehlers, sondern nur der Ort, an dem er auffällt.

Diese Anleitung setzt voraus, dass du bereits einen laufenden Workflow hast — etwa aus n8n-Workflow selbst erstellen und testen. Sie zeigt an einer fiktiven Übung, wie man den ersten fehlerhaften Knoten eingrenzt, statt den ganzen Ablauf zu raten oder neu zu bauen.

Was du dafür brauchst

Du brauchst Zugriff auf eine n8n-Instanz mit Bearbeitungsrechten für den betroffenen Workflow und die Berechtigung, seine Ausführungen (Executions) einzusehen. Laut n8n-Dokumentation zeigt die Ausführungsliste eines Workflows alle bisherigen Läufe mit ihrem Status; darüber lassen sich fehlgeschlagene wie erfolgreiche, aber inhaltlich falsche Läufe erneut aufrufen. Die Funktion Debug in editor beziehungsweise Copy to editor lädt die Daten eines vergangenen Laufs zurück in den Editor, sodass Knoten mit den echten Eingangsdaten des Fehlerfalls angesehen werden können, ohne das externe System erneut aufzurufen.

Die fiktive Übung: eine falsch eingeordnete Bestellung

Fiktive Übung mit angenommenen Testdaten, kein Kundenprojekt. Ein Workflow soll eingehende Bestellungen aus einem Webhook prüfen: Bestellungen über 5.000 Euro sollen an einen Freigabeschritt gehen, alle anderen direkt verbucht werden. Der Ablauf ist:

Webhook → Bestellwert normalisieren (Edit Fields) → If: Bestellwert über 5000? → Freigabe anfordern / Direkt verbuchen

Testfall: Eine Bestellung mit dem Wert „8.200,00 €“ als Text im eingehenden Feld bestellwert kommt an. Erwartet wird der Weg Freigabe anfordern. Tatsächlich läuft sie über Direkt verbuchen — ohne dass n8n einen Fehler meldet. Das ist der unauffälligste und deshalb schwierigste Fehlertyp: kein rot markierter Knoten, nur ein falsches Ergebnis.

Schritt 1: Den betroffenen Lauf in den Editor laden

Öffne im Workflow den Reiter Executions und suche den Lauf mit der 8.200-Euro-Bestellung. Wähle Copy to editor (bei einem technisch fehlgeschlagenen Lauf Debug in editor). n8n legt die Daten dieses Laufs als fixierte Daten (Pin Data) am ersten Knoten ab. Damit lässt sich der Fall beliebig oft mit exakt denselben Werten durchgehen, ohne den Webhook erneut auszulösen.

Für neue Übungsfälle ohne bereits aufgezeichneten Lauf legst du dieselben Werte stattdessen manuell in einem Testknoten an und fixierst sie — das Ergebnis für den Vergleich ist dasselbe.

Schritt 2: Von vorne nach hinten vergleichen, nicht vom Ende her raten

Bevor Werte kontrolliert werden, wird für jeden Knoten kurz notiert, was erwartet wird:

| Knoten | Erwarteter Eingang | Erwartete Ausgabe | |---|---|---| | Webhook | — | bestellwert: "8.200,00 €" | | Bestellwert normalisieren | bestellwert: "8.200,00 €" | bestellwert_zahl: 8200 | | If: über 5000? | bestellwert_zahl: 8200 | Ausgang true |

Jetzt wird Knoten für Knoten die tatsächliche Ein- und Ausgabe im Input-/Output-Bereich des Editors angesehen:

• Webhook: Eingang entfällt, Ausgabe zeigt bestellwert: "8.200,00 €" — stimmt mit der Erwartung überein.
• Bestellwert normalisieren: Eingang zeigt exakt "8.200,00 €" — stimmt ebenfalls. Ausgabe zeigt aber bestellwert_zahl: 0, nicht 8200. Hier weicht die tatsächliche Ausgabe zum ersten Mal von der erwarteten ab — das ist der erste fehlerhafte Knoten.

Der If-Knoten dahinter muss gar nicht mehr im Detail geprüft werden: Er bekommt korrekt 0 als Eingang und wertet ihn korrekt als „nicht über 5000“ aus. Der If-Knoten ist nicht defekt, er verarbeitet nur einen bereits falschen Wert weiter. Wer stattdessen zuerst am Ende ansetzt, würde vermutlich die Bedingung im If-Knoten ändern — und einen neuen Fehler einbauen, ohne den eigentlichen zu beheben.

Schritt 3: Am fehlerhaften Knoten die Datenzuordnung prüfen

Am Knoten „Bestellwert normalisieren“ liegt der Fehler in der Datenzuordnung: Die Formel wandelt {{$json.bestellwert}} direkt in eine Zahl um, ohne vorher das Euro-Zeichen, den Tausenderpunkt und das Komma als Dezimaltrennzeichen zu entfernen. Aus dem Text „8.200,00 €“ entsteht bei dieser Umwandlung keine gültige Zahl, das Feld fällt auf 0 zurück.

Die Korrektur entfernt zuerst alle Zeichen außer Ziffern und Komma, ersetzt danach das Komma durch einen Punkt und wandelt erst danach in eine Zahl um. Wichtig ist die Reihenfolge: Wird zuerst in eine Zahl umgewandelt und erst danach bereinigt, bleibt der Fehler bestehen, weil zu diesem Zeitpunkt schon 0 im Feld steht.

Schritt 4: Erwartetes Ergebnis prüfen

Nach der Korrektur wird derselbe fixierte Testfall erneut ausgeführt:

| Testwert bestellwert | Erwartete bestellwert_zahl | Erwarteter Ausgang am If-Knoten | |---|---|---| | „8.200,00 €“ | 8200 | true → Freigabe anfordern | | „450,00 €“ | 450 | false → Direkt verbuchen | | „5.000,00 €“ | 5000 | false → Direkt verbuchen (Grenzwert nicht überschritten) |

Das sind erwartete Ergebnisse der festgelegten Übungsregel, keine Messwerte aus einem echten Betrieb. Wichtig ist der zweite und dritte Fall: Sie liefen vor der Korrektur bereits richtig durch Zufall über denselben fehlerhaften Weg. Erst der erneute Test aller drei Werte zeigt, ob die Korrektur den ursprünglichen Fehler behebt, ohne die bisher richtigen Fälle zu verändern.

Wenn die Abweichung schon am Eingang auftritt

Nicht jeder Fehler liegt in der Datenzuordnung eines Knotens. Zeigt bereits der Eingang eines Knotens nicht das erwartete Feld — etwa weil ein vorheriger Knoten das Feld anders benannt, gar nicht mitgegeben oder nur für einen Teil der Datensätze gefüllt hat — liegt die Ursache einen Schritt weiter vorne. Die Prüfreihenfolge bleibt gleich: erst den Eingang mit der Erwartung vergleichen, dann die Zuordnung im Knoten selbst, erst danach die Ausgabe. Wer diese drei Stellen vertauscht, verwechselt leicht eine Folge des Fehlers mit seiner Ursache.

Wo diese Methode an ihre Grenzen kommt

Bei Fehlern, die nur bei bestimmten Datenmengen, gleichzeitigen Läufen oder zeitlich verzögerten Antworten externer Systeme auftreten, reicht der Vergleich einzelner fixierter Testfälle nicht aus — dafür braucht es wiederholte Läufe unter echten Bedingungen, und Pin-Daten sind laut n8n-Dokumentation ausdrücklich nur für die Entwicklung gedacht, nicht für produktive Ausführungen. Bei Workflows, die personenbezogene oder vertrauliche Daten verarbeiten, dürfen Ausführungsdaten außerdem nicht unbegrenzt aufbewahrt oder ungeprüft weitergegeben werden, nur weil sie zur Fehlersuche praktisch sind — welche Aufbewahrungsfrist zulässig ist, hängt vom Einzelfall ab und ist keine rein technische Entscheidung.

Der nächste Schritt

Diese Methode ist eine Ergänzung zum Einstieg, keine Wiederholung: Wie ein erster eigener Workflow überhaupt aufgebaut wird, steht in n8n-Workflow selbst erstellen und testen. Weitere typische Fehlerfälle wie doppelte Eingänge oder unterbrochene Verbindungen sammelt unsere Übung Automatisierung testen. Wenn du an einem eigenen Workflow hängst und nicht weiterkommst, hilft in der KI-Beratung und Hilfe beim Aufbau ein Blick von außen auf genau den Knoten, an dem Eingang, Zuordnung und Ausgabe nicht mehr zusammenpassen.