Warum n8n parallele Branches nicht gleichzeitig ausführt und worauf der Merge-Node wirklich wartet, laut offizieller Doku erklärt.
Wenn Sie in n8n einen Workflow bauen, der sich nach einem If- oder Switch-Node in mehrere Branches aufteilt, gehen Sie vermutlich davon aus, dass diese Branches gleichzeitig laufen und sich am Merge-Node einfach wieder treffen. Genau diese Annahme sorgt regelmäßig für Verwirrung, denn n8n führt Branches nicht parallel im Sinne von gleichzeitig aus, sondern nach einer festen, nachvollziehbaren Reihenfolge. Wer diese Reihenfolge nicht kennt, wundert sich über Ausführungen, die scheinbar in der falschen Reihenfolge passieren, über API-Aufrufe, die sich gegenseitig überholen, oder über einen Merge-Node, der ewig zu hängen scheint.
Die gute Nachricht: Die Logik dahinter ist klar dokumentiert und lässt sich mit ein paar Grundregeln zuverlässig vorhersagen. In diesem Artikel schauen wir uns an, wie n8n die Execution Order bestimmt, was sich mit Version 1.0 geändert hat, und worauf der Merge-Node wirklich wartet, wenn Sie seine Logik einmal verstanden haben. So behalten Sie die Kontrolle über Ihre Workflows, auch wenn sie mit jedem weiteren Branch komplexer werden.
n8n unterscheidet laut der offiziellen Dokumentation zur Execution Order zwischen zwei grundsätzlich verschiedenen Ausführungsmodi, abhängig davon, wann ein Workflow angelegt wurde:
Dieser Unterschied ist der Kern der meisten Missverständnisse. Wer mit einem älteren Workflow arbeitet oder eine Vorlage aus einem älteren Tutorial übernimmt, erlebt ein anderes Verhalten als jemand, der einen frisch angelegten Workflow in einer aktuellen n8n-Version baut. Beide Modi lassen sich laut Dokumentation über die Workflow-Einstellungen anpassen, falls Sie gezielt das jeweils andere Verhalten brauchen.
Für Workflows ab Version 1.0 gilt eine feste, nachvollziehbare Regel: n8n orientiert sich an der Position der Nodes auf der Canvas. Branches werden von oben nach unten abgearbeitet. Liegen zwei Branches auf derselben Höhe, entscheidet die horizontale Position, wobei der linke Branch zuerst ausgeführt wird.
Das bedeutet praktisch: Wenn Sie in Ihrem Workflow zwei oder drei parallele Zweige nach einem Switch-Node anordnen, bestimmt allein die visuelle Anordnung auf der Canvas, welcher Zweig zuerst dran ist, nicht die Reihenfolge, in der Sie die Verbindungen gezogen haben, und auch nicht irgendeine interne ID. Das ist besonders wichtig, wenn einzelne Branches Seiteneffekte haben, etwa Schreibzugriffe auf dieselbe Tabelle, Aktualisierungen desselben CRM-Datensatzes oder Aufrufe derselben rate-limitierten API. Läuft ein Branch vor dem anderen, kann das Ergebnis des zweiten Branches vom ersten abhängen, selbst wenn das im Workflow-Design gar nicht so gedacht war.
Der Merge-Node kombiniert Daten aus mehreren Quellen zu einem Stream. Im Append-Modus gilt eine einfache, aber oft übersehene Regel: Der Node wartet, bis alle verbundenen Eingänge ausgeführt wurden, bevor er selbst weiterläuft. Erst wenn jeder Input Daten oder explizit keine Daten geliefert hat, gibt der Merge-Node etwas aus.
Das erklärt zwei häufige Beobachtungen aus der Praxis:
Seit dem größeren Umbau des Merge-Nodes in Version 0.194.0 und der Erweiterung um mehr als zwei Eingänge sowie den SQL-Query-Modus in Version 1.49.0 lassen sich außerdem mehr als zwei Branches gleichzeitig zusammenführen, was die klassische Zwei-Branch-Logik in größeren Workflows deutlich vereinfacht. Details zu allen Merge-Modi wie Append, Combine und Choose Branch finden Sie in der Anleitung zum Zusammenführen von Datenströmen.
Besonders tückisch ist ein Verhalten, das laut Dokumentation ausschließlich Workflows mit der v0-Legacy-Ausführungsreihenfolge betrifft, also standardmäßig alle vor Version 1.0 gebauten Workflows. Fügen Sie in einem solchen Workflow einen Merge-Node zu einer Struktur hinzu, die einen If-Node enthält, kann es passieren, dass beide Output-Streams des If-Nodes ausgeführt werden, obwohl der If-Node eigentlich nur einen der beiden Pfade auslösen sollte. Der Grund: Ein Datenstream löst den Merge-Node aus, der daraufhin auch den anderen, eigentlich inaktiven Datenstream mit ausführt.
Dieses Verhalten wurde mit Version 1.0 entfernt. Wer also einen alten Workflow migriert oder weiterpflegt und unerklärliche doppelte Ausführungen nach einem If-Node beobachtet, findet hier oft die Ursache. Ein Wechsel auf die neue Execution Order in den Workflow-Einstellungen behebt das Problem in der Regel zuverlässig.
Bevor Sie einen bestehenden Workflow debuggen, lohnt sich ein kurzer Check in den Workflow-Einstellungen: Dort sehen Sie, welche Execution Order aktuell aktiv ist, und können bei Bedarf zwischen v0 und v1.0 wechseln. Für neue Workflows empfiehlt sich grundsätzlich die aktuelle Logik, weil sie vorhersagbarer ist und die beschriebene If-plus-Merge-Falle gar nicht erst auftritt.
Bei komplexeren Automatisierungen mit mehreren parallelen Branches und Seiteneffekten lohnt es sich zusätzlich, die Canvas-Anordnung bewusst zu nutzen: Platzieren Sie den Branch, der zuerst laufen soll, oben beziehungsweise links, und halten Sie diese Absicht im Workflow selbst fest, etwa über eine Sticky Note. So bleibt für jeden im Team nachvollziehbar, warum die Reihenfolge genau so gewählt wurde, und niemand muss die Logik beim nächsten Umbau neu erraten. Wenn Ihre Automatisierungen so verzweigt sind, dass sich die Reihenfolge nicht mehr auf einen Blick erschließt, unterstützen wir Sie mit unserer n8n-Automatisierung dabei, Workflows sauber und nachvollziehbar zu strukturieren.
Nein, zumindest nicht im Sinne von gleichzeitiger Ausführung. In Workflows ab Version 1.0 arbeitet n8n einen Branch komplett ab, bevor der nächste beginnt, gesteuert durch die Position der Nodes auf der Canvas. In älteren v0-Workflows läuft stattdessen Node für Node schichtweise über alle Branches hinweg, was ebenfalls keine echte Parallelität ist.
Der Merge-Node wartet im Append-Modus auf die Ausführung aller verbundenen Eingänge. Läuft einer der vorherigen Branches nicht durch, etwa weil eine Bedingung nicht erfüllt ist oder ein Node einen Fehler wirft, bekommt der Merge-Node von diesem Input nie ein Signal und bleibt entsprechend ohne Ausgabe.
Die Items an Input 1 haben Vorrang. Bekommt der Merge-Node etwa fünf Items an Input 1 und zehn an Input 2, verarbeitet er nur fünf Items, weil Input 1 die Obergrenze für die Verarbeitung vorgibt.
Nein. Laut n8n-Dokumentation gilt dieses Verhalten ausschließlich für Workflows mit der v0-Legacy-Ausführungsreihenfolge, also standardmäßig für alle vor Version 1.0 erstellten Workflows. In neu angelegten Workflows mit der aktuellen Execution Order tritt dieses Problem nicht mehr auf.
Ja. Die Execution Order lässt sich in den Workflow-Einstellungen umstellen. Das ist besonders bei älteren, migrierten Workflows sinnvoll, wenn Sie unerklärliche Mehrfachausführungen nach If- oder Switch-Nodes beobachten und die Ursache in der veralteten v0-Logik vermuten.
Gründer von NordFlux. Sieben Jahre Erfahrung von Web und SEO bis zur Automatisierung im Konzern-Maßstab, heute pragmatisch für den Mittelstand und mit deutscher Datenhoheit.
Zertifizierungen
Wie lange n8n die Execution-History je Plan speichert (Starter bis Enterprise), wichtig für Debugging und Nachweispflichten bei Buchhaltungs-Workflows.
Warum die n8n-Datenbank durch Executions wächst und wie EXECUTIONS_DATA_PRUNE, Aufbewahrungsdauer und Limits die Datenmenge automatisch begrenzen.
Wenn der Merge-Node auf die falsche Reihenfolge wartet, entstehen Fehler, die sich im Test kaum zeigen und erst im Betrieb auffallen. NordFlux prüft Execution Order und Merge-Logik Ihrer n8n-Workflows und baut sie so um, dass Branches zuverlässig zusammenlaufen. Im ersten Gespräch gehen wir Ihre kritischen Workflows gemeinsam durch.
