Loop Over Items in n8n: Wann Sie eine Schleife brauchen

Zwei Sätze höre ich in Gesprächen mit Betrieben immer wieder, sobald jemand zum ersten Mal selbst einen Workflow in n8n baut. Der eine: „Ich muss doch bestimmt eine Schleife bauen, damit das für alle 200 Datensätze läuft?“ Der andere, ratlos: „Warum verarbeitet mein Node nur den ersten Eintrag?“ Beide Fragen kommen aus derselben Wissenslücke – nämlich, wie n8n Daten überhaupt durch einen Workflow schiebt. Wer das Modell dahinter einmal verstanden hat, spart sich überflüssige Schleifen und weiß umgekehrt genau, wann eine echte gebraucht wird. Dieser Artikel ist für alle, die selbst an n8n-Workflows bauen.

Ein Node, viele Items – und warum n8n von allein iteriert

n8n reicht Daten nicht als einen großen Block weiter, sondern als Liste einzelner Items. Ein Item ist ein Datensatz: eine Zeile in der Ausgabetabelle eines Nodes, etwa ein Kontakt, eine Rechnung oder eine Bestellung. Der entscheidende Punkt ist, dass ein Node standardmäßig einmal pro Item läuft. Hängen Sie an einen Node mit fünf Kontakten einen Send Email-Node, verschickt n8n fünf E-Mails – eine je Item, ganz ohne dass Sie etwas verschleifen müssten. Diese Wiederholung erledigt n8n laut offizieller Doku automatisch; Schleifen müssen Sie dafür nicht selbst bauen.

In n8n ist ein Item ein einzelner Datensatz, und jeder Node läuft standardmäßig einmal pro Item. Eine Liste mit 200 Datensätzen wird also 200-mal durch den Node geschickt, ohne dass Sie eine Schleife anlegen. Das automatische Iterieren ist der Normalfall – eine eigene Schleife ist die Ausnahme, nicht die Regel.

Der umgekehrte Fall kommt seltener vor, ist aber ebenso wichtig: Manchmal wollen Sie, dass ein Node eben nicht alle Items abarbeitet, sondern nur den ersten – etwa eine Benachrichtigung, die genau einmal rausgehen soll. Dafür gibt es den Schalter Execute Once im Reiter Settings des jeweiligen Nodes. Ist er aktiv, verarbeitet der Node nur das erste eingehende Item und ignoriert den Rest.

Wann ein Node eben nicht automatisch iteriert

Es gibt eine überschaubare Liste von Nodes, bei denen das automatische Iterieren nicht greift – weil sie ihre Eingabe technisch in einem Rutsch verarbeiten. Die n8n-Doku führt sie als „Node exceptions“. Die wichtigsten:

Node / Modus	Verhalten
HTTP Request	läuft einmal – paginierte Ergebnisse holen Sie selbst per Schleife
Code und Execute Workflow im Modus „Run Once for All Items“	verarbeiten alle Items in einem Durchlauf
RSS Read	läuft einmal je angeforderter URL
Redis	läuft einmal, unabhängig von der Zahl der Items
CrateDB, Microsoft SQL, MongoDB, QuestDB, TimescaleDB	führen Insert/Update in einem Rutsch aus

Bei diesen Nodes ist das oft genau richtig so: Ein Datenbank-Node, der 500 Zeilen mit einem einzigen Insert schreibt, ist schneller und schonender als 500 Einzelaufrufe. Erst wenn Sie pro Item ein anderes Verhalten brauchen, bauen Sie hier bewusst eine Schleife. Der Code-Node hat dafür sogar einen eigenen Umschalter: Im Modus „Run Once for Each Item“ läuft Ihr Skript wieder pro Datensatz statt einmal über alle – mehr dazu im Leitfaden zum Code-Node.

Die Loop-Over-Items-Node: wofür sie wirklich da ist

Wenn n8n ohnehin von allein iteriert – wozu dann überhaupt eine Schleife? Für die Fälle, in denen Sie nicht ein Item nach dem anderen, sondern Gruppen von Items in kontrollierten Runden verarbeiten wollen. Genau das macht die Loop Over Items-Node (früher Split in Batches).

Sie hat einen zentralen Parameter und zwei Ausgänge, und beide muss man auseinanderhalten:

• Batch Size legt fest, wie viele Items pro Runde durch den loop-Ausgang gehen. Setzen Sie den Wert auf 1, wird jedes Item einzeln bearbeitet; bei 10 gehen zehn auf einmal durch.
• Der loop-Ausgang führt die aktuelle Runde in die Schritte, die pro Batch laufen sollen.
• Der done-Ausgang feuert erst, wenn alle Runden durch sind. Er bündelt die gesammelten Ergebnisse und führt sie in den restlichen Workflow. Hier hängen Sie alles an, was am Ende genau einmal passieren soll.

Der Node merkt sich die ursprüngliche Eingabe und gibt mit jeder Runde die nächste Portion aus. Die Ergebnisse werden automatisch wieder zusammengeführt – anders als bei einer selbstgebauten Schleife brauchen Sie also keinen IF-Node, um das Ende zu erkennen.

Konkret lohnt sich die Loop Over Items-Node in diesen Situationen:

1. Ein Ziel-System akzeptiert nur eine begrenzte Zahl an Datensätzen pro Aufruf – dann setzen Sie die Batch Size genau auf diese Grenze.
2. Pro Runde sollen mehrere Schritte laufen und Sie brauchen am Schluss das Gesamtergebnis: Der done-Ausgang sammelt es für Sie ein.
3. Sie arbeiten mit einer der Ausnahme-Nodes von oben, etwa einer paginierten API-Abfrage.

Für fortlaufende Muster wie Pagination gibt es zusätzlich die Option Reset: Ist sie aktiv, initialisiert der Node die Eingabedaten mit jeder Runde neu, statt die ursprüngliche Liste weiter abzuarbeiten. Wie weit die Schleife gerade ist, verrät übrigens der Ausdruck {{ $('Loop Over Items').context['currentRunIndex'] }}; ob noch Items ausstehen, liefert ...context['noItemsLeft'] als Ja/Nein-Wert.

Der häufigste Fehler: „läuft nur einmal“

Der Klassiker im n8n-Forum: Die Loop Over Items-Node verarbeitet scheinbar nur die erste Runde und hört dann auf. Fast immer liegt es an der Verdrahtung. Die Nodes, die pro Runde laufen sollen, hängen am loop-Ausgang – und ihr letzter Node muss zurück auf den Eingang der Loop Over Items-Node zeigen. Ohne diese Rückverbindung dreht sich die Schleife kein zweites Mal. Der done-Ausgang führt dagegen nach vorne zum Rest des Workflows. Wer die beiden Ausgänge vertauscht, bekommt entweder einen Durchlauf, der zu früh abbricht, oder im ungünstigen Fall eine Schleife, die sich nicht sauber schließt.

Batching ist nicht Drosselung – und nicht Pagination

Drei Dinge werden gern verwechselt, weil überall das Wort „Batch“ fällt:

• Automatisches Iterieren: n8n schickt jedes Item einzeln durch den Node – kostenlos und ohne Ihr Zutun.
• Batching mit Loop Over Items: Sie bündeln Items in Runden, um sie kontrolliert zu verarbeiten oder am Ende zusammenzuführen.
• Drosselung gegen Rate Limits: eine Schleife plus Wartezeit, damit Sie das Anfragelimit einer API nicht reißen. Das ist ein eigenes Thema, das ich unter HTTP 429 in n8n abfangen ausführlich behandelt habe.

Und die Pagination – das seitenweise Nachladen von API-Ergebnissen – bringt der HTTP Request-Node inzwischen selbst mit; wann Sie sie brauchen und wie Sie sie einstellen, steht in alle Daten trotz Pagination holen. Wer diese drei Ebenen sauber trennt, baut nicht aus Versehen eine Schleife, wo n8n die Arbeit längst allein erledigt.

Fazit

Die wichtigste Erkenntnis ist eine Entlastung: In n8n müssen Sie fast nie eine Schleife bauen. Der Node läuft von allein einmal pro Datensatz, und nur bei einer Handvoll Ausnahme-Nodes oder wenn Sie Items bewusst in Runden bündeln, greifen Sie zur Loop Over Items-Node – mit klarer Trennung zwischen loop und done. Wer dieses Modell kennt, baut schlankere und nachvollziehbarere Workflows, die auch dann noch laufen, wenn statt drei Testdatensätzen plötzlich fünfhundert echte durchlaufen.

Wenn Sie unsicher sind, ob sich ein Prozess sauber in n8n abbilden lässt – oder ob ein bestehender Workflow unnötig kompliziert gebaut ist – schauen wir uns das im kostenlosen Prozess-Check gemeinsam an. Und wenn Sie n8n als Plattform grundsätzlicher einordnen wollen, finden Sie den Rahmen dazu auf der Seite zur n8n-Beratung.