Workflows testen: Pin Data, Mock Data, Debug-Modus

Wer an einem n8n-Workflow arbeitet, der eine E-Mail verschickt, eine Zahlung auslöst oder einen Datensatz in ein CRM schreibt, will beim Testen nicht jedes Mal eine echte Nachricht verschicken oder einen echten Kundendatensatz anlegen. Genau dafür bietet n8n zwei ineinandergreifende Funktionen: Pin Data friert die Ausgabe eines Knotens ein, Mock Data erzeugt Testdaten, ohne überhaupt eine externe Quelle anzusprechen. Ergänzt wird das durch den Debug-Modus, mit dem sich fehlgeschlagene Produktiv-Ausführungen direkt im Editor nachstellen lassen.

Für dich als Team, das produktive Automatisierungen aufbaut, ist das mehr als ein Komfort-Feature. Ohne fixierte Testdaten testest du bei jedem Klick auf "Execute workflow" gegen echte Systeme, verbrauchst API-Kontingente und riskierst, dass ein Test versehentlich eine echte Aktion auslöst. Mit Pin Data, Mock Data und dem Debug-Modus behältst du die Kontrolle darüber, welche Daten wann durch deinen Workflow laufen, und kannst dieselbe Logik zuverlässig mehrfach mit denselben Eingaben prüfen.

Warum Testdaten fixieren statt live gegen Produktivsysteme zu testen

Ein typisches Problem beim Bauen von Workflows: Der erste Knoten holt Daten aus einer externen Quelle, etwa einem Webhook, einer Tabelle oder einer API. Jedes Mal, wenn du den Workflow zum Testen ausführst, läuft diese Anfrage erneut, kostet Zeit, verbraucht möglicherweise ein Kontingent und liefert nicht garantiert dieselben Werte wie beim letzten Durchlauf. Genau hier setzen Pin Data und Mock Data an: Beide Funktionen sind laut n8n als Werkzeuge zum Testen während der Entwicklung gedacht, "um Zeit und Ressourcen während der Entwicklung zu sparen, mit konsistenten Datensätzen zu arbeiten und Live-Systeme vor wiederholten Testaufrufen zu schützen". Statt bei jedem Testlauf gegen ein echtes System zu feuern, arbeitest du mit einem festen, wiederholbaren Datensatz und siehst sofort, ob eine Änderung an deiner Logik das gewünschte Ergebnis bringt.

Pin Data: Node-Ausgabe einfrieren

Data Pinning speichert die Ausgabedaten eines Knotens und nutzt diese gespeicherten Daten bei zukünftigen Ausführungen, statt erneut frische Daten abzurufen. So gehst du dabei vor:

• Führe den betreffenden Knoten einmal aus, damit Daten in der OUTPUT-Ansicht erscheinen.
• Klicke in der OUTPUT-Ansicht auf das Pin-Symbol. Ein Banner bestätigt, dass die Daten jetzt angepinnt sind.
• Über den Link Unpin im selben Banner löst du die Fixierung wieder, danach ruft der Knoten beim nächsten Lauf wieder frische Daten ab.
• Angepinnte Daten lassen sich auch nachträglich bearbeiten: Wechsle in der OUTPUT-Ansicht in die JSON-Ansicht, wähle Edit, passe die Werte an und speichere mit Save.

Besonders praktisch ist das bei Workflows, die durch ein externes System wie einen Webhook ausgelöst werden: Ist die Startdaten einmal angepinnt, musst du das auslösende System nicht bei jedem Test erneut anstoßen, sondern arbeitest direkt mit dem fixierten Datensatz weiter. Du kannst dafür auch Daten aus einer früheren Ausführung wiederverwenden: Im Tab Executions eine vergangene Ausführung öffnen, den gewünschten Knoten per Doppelklick öffnen, in die JSON-Ansicht wechseln, die Daten kopieren und in der Zielansicht eines Knotens einfügen und speichern.

Mock Data: Testdaten ganz ohne echte Quelle erzeugen

Data Mocking bedeutet, Testdaten zu erstellen oder zu simulieren, ohne dich überhaupt mit einer realen Datenquelle zu verbinden. Das ist immer dann hilfreich, wenn du noch keinen Zugriff auf das echte System hast, ein Randfall getestet werden soll, den die echten Daten gerade nicht liefern, oder wenn du unabhängig von Verfügbarkeit und Rechten einer externen Quelle entwickeln willst. n8n nennt dafür in erster Linie zwei Wege:

• Edit-Fields-Knoten oder Code-Knoten: Für kleine, überschaubare Testfälle eignet sich der Edit-Fields-Knoten, mit dem du einzelne Felder und Werte von Hand setzt. Für komplexere Datenstrukturen oder gezielte Randfälle gibt der Code-Knoten dir volle Kontrolle über Aufbau und Inhalt der Testdaten.
• Customer-Datastore-Knoten: Dieser Knoten liefert einen fertigen Beispiel-Datensatz, wenn du gerade keine eigenen Testdaten zur Hand hast und trotzdem mit realistisch aussehenden Datensätzen weiterarbeiten willst.

In der Praxis kombinierst du beide Funktionen häufig: Du erzeugst zunächst Mock Data für ein bestimmtes Testszenario, passt die Werte gezielt an und pinnst sie anschließend, damit du dieselbe Situation bei jedem weiteren Testlauf exakt wieder vorfindest.

Grenzen von Pin Data und Mock Data

Beide Funktionen sind ausdrücklich für die Entwicklungsphase gedacht, nicht für den laufenden Betrieb. Laut der offiziellen n8n-Dokumentation zu Pin Data und Mock Data gilt:

• Data Pinning steht für produktive Workflow-Ausführungen nicht zur Verfügung. Sobald ein Workflow aktiviert läuft, ignoriert n8n angepinnte Daten und ruft echte Daten ab.
• Du kannst keine Daten anpinnen, wenn die Ausgabe Binärdaten enthält.
• Data Pinning funktioniert nur bei Knoten mit genau einem einzigen Hauptausgang.

Diese Einschränkungen sind kein Zufall: Sie verhindern, dass fixierte Testdaten versehentlich in produktive Läufe durchsickern und dort veraltete oder falsche Werte liefern. Wenn du einen Workflow für den produktiven Einsatz freigibst, solltest du deshalb vor der Aktivierung noch einmal gezielt prüfen, ob noch irgendwo angepinnte Testdaten liegen.

Debug-Modus: Mit echten Fehlerdaten nacharbeiten

Der Debug-Modus setzt genau da an, wo Pin Data und Mock Data aufhören: bei einer bereits gelaufenen, aber fehlgeschlagenen Produktiv-Ausführung. Laut der n8n-Dokumentation zum Debuggen von Ausführungen lädt diese Funktion die Daten einer vergangenen Ausführung in deinen aktuellen Workflow, was besonders beim Nachvollziehen fehlgeschlagener Produktiv-Läufe wertvoll ist. So gehst du vor:

• Öffne im Workflow den Tab Executions, um die Ausführungshistorie zu sehen.
• Wähle die Ausführung aus, die du untersuchen willst.
• Bei fehlgeschlagenen Ausführungen klickst du auf Debug in editor, bei erfolgreichen auf Copy to editor.
• n8n überträgt die Ausführungsdaten automatisch in deinen Workflow-Editor und pinnt die Daten dabei am ersten Knoten des Workflows.

Damit kannst du exakt mit den Daten weiterarbeiten, die den Fehler ausgelöst haben, deine Korrektur direkt gegen diesen Fall testen und erst danach wieder live schalten. Die Funktion steht laut n8n auf n8n Cloud sowie für registrierte Community-Instanzen zur Verfügung; welche Ausführungen dabei überhaupt in der Liste erscheinen, hängt zusätzlich von den Aufbewahrungseinstellungen deines Workflows ab.

Wenn du n8n-Workflows produktiv betreibst und dabei nicht bei jedem Fehler von vorn anfangen willst, lohnt sich eine feste Routine: Testdaten pinnen, bevor du an der Logik arbeitest, echte Fehlerfälle über den Debug-Modus nachstellen, und erst nach einem sauberen Testlauf ohne angepinnte Daten wieder scharf schalten. Bei der Automatisierung mit n8n bauen wir solche Testroutinen von Anfang an in die Workflows unserer Kunden ein, damit Änderungen nicht auf Verdacht gegen Produktivsysteme laufen.

Häufige Fragen

Kann ich Pin Data auch bei einem Webhook-Trigger nutzen?

Ja. Gerade wenn ein Workflow durch ein externes System wie einen Webhook-Aufruf gestartet wird, hilft Pin Data dabei, dass du das auslösende System nicht bei jedem Test erneut ansprechen musst. Du pinnst die einmal empfangenen Startdaten und arbeitest danach direkt mit diesem fixierten Datensatz weiter.

Funktioniert Pin Data auch mit Binärdaten wie Dateien oder Bildern?

Nein. Enthält die Ausgabe eines Knotens Binärdaten, lässt sich diese Ausgabe laut n8n-Dokumentation nicht anpinnen. Für solche Fälle bleibt nur, die Binärquelle beim Testen tatsächlich einmal live anzusprechen oder mit einem vereinfachten Ersatzdatensatz ohne Binäranteil zu arbeiten.

Was passiert mit angepinnten Testdaten, wenn ich den Workflow aktiviere?

Nichts Problematisches, solange du sauber gearbeitet hast: Data Pinning ist für produktive Ausführungen nicht wirksam, ein aktivierter Workflow ruft also automatisch wieder echte Daten ab. Es lohnt sich trotzdem, vor dem Livegang bewusst zu prüfen, ob noch angepinnte Testdaten in einzelnen Knoten liegen, um Verwirrung beim nächsten Bearbeiten zu vermeiden.

Worin unterscheiden sich Pin Data und Mock Data konkret?

Mock Data erzeugt einen Testdatensatz von Grund auf, zum Beispiel über den Edit-Fields- oder Code-Knoten, ganz ohne echte Datenquelle. Pin Data dagegen friert die tatsächliche Ausgabe eines Knotens ein, egal ob diese Ausgabe aus einem echten Systemaufruf stammt oder zuvor selbst als Mock Data erzeugt wurde. In der Praxis werden beide Funktionen oft kombiniert.

Ist der Debug-Modus auch bei einer selbst gehosteten n8n-Instanz verfügbar?

Laut n8n-Dokumentation steht die Debug-Funktion auf n8n Cloud sowie für registrierte Community-Instanzen zur Verfügung. Welche konkreten Ausführungen dabei im Verlauf auftauchen und wie lange sie aufbewahrt werden, hängt zusätzlich von den Workflow-Einstellungen zur Aufbewahrung von Ausführungsdaten ab.