n8n Loop Over Items: batching and loops

The n8n Loop Over Items node, formerly called Split in Batches, splits incoming items into batches and feeds them through part of a workflow one batch at a time. It is also the node most people add when they don't need it. Before configuring it, it helps to know how n8n already loops for you.

n8n loops by default

Nodes in n8n receive a list of items and run once per item (looping docs). Connect a Slack node to a node that outputs 50 contacts and you get 50 messages. No loop node, no for statement.

So the question isn't "how do I loop", it is "do I need to control how the items flow?". The answer is yes in three situations:

1. Rate limits. You need to send items in groups with a pause between groups.
2. Nodes that process only one item. Some nodes or operations run once regardless of input.
3. Stateful loops. Each iteration depends on the previous one, for example fetching pages until an empty page.

If none of these applies, remove the loop.

How the node works

The node stores all incoming items. On each iteration it emits Batch Size items through the loop output. You connect the processing nodes to that output and wire the last one back into Loop Over Items. When every batch has been processed, the node emits all results at once through the done output.

Get rows → Loop Over Items ─loop→ HTTP Request → Wait (1 s) ─┐
                 ▲                                            │
                 └────────────────────────────────────────────┘
                 └─done→ Summarize → Slack

Setting	Meaning
Batch Size	Items per iteration. 1 processes items one by one
Reset (option)	Treat incoming data as a new set on each pass, used for open-ended loops

Useful expressions from the node docs:

Expression	Returns
{{ $("Loop Over Items").context["noItemsLeft"] }}	true when no batches remain
{{ $("Loop Over Items").context["currentRunIndex"] }}	Current iteration index

In workflow JSON the node's type is still n8n-nodes-base.splitInBatches.

Use case 1: respect a rate limit

An API allows 10 requests per second and you have 2,000 records.

• Loop Over Items, Batch Size 10
• On the loop output: HTTP Request, then a Wait node set to 1 second
• Wait connects back to Loop Over Items
• The done output continues the workflow

For simple cases the HTTP Request node's own Batching option (Items per Batch, Batch Interval) does the same without a loop. Use Loop Over Items when several nodes must run per batch, for example request, transform and write to a database.

Use case 2: nodes that process one item

The looping docs list node exceptions that don't iterate over all items, including:

• RSS Read (once for the requested URL)
• Code node in Run Once for All Items mode (runs once, by design)
• Execute Sub-workflow node in Run Once for All Items mode
• Some database operations: MongoDB insert and update, Microsoft SQL insert, update and delete, Redis Info, and a few others

To read several RSS feeds, put Loop Over Items with Batch Size 1 before RSS Read, so each URL gets its own run. The n8n docs show this with two feeds.

Use case 3: paginate with an unknown page count

Most APIs can be paginated with the HTTP Request node's built-in Pagination option. When the logic is more complex (each page needs processing before the next request, or the next page depends on processed data), build the loop yourself:

1. A Code or Edit Fields node sets page = 1.
2. Loop Over Items with Reset turned on.
3. HTTP Request fetches page.
4. Processing nodes.
5. If node: "results are empty" → exit; otherwise a node that increments page and connects back to Loop Over Items.

The docs warn that a loop with Reset needs a valid termination condition, otherwise the execution never ends. Add a second guard, such as page < 500, so a misbehaving API can't keep the loop running forever.

Collecting results

The done output returns everything processed by the loop, combined. That's where totals, reports and "one Slack message at the end" belong.

If you need results from a specific node inside the loop in a Code node after the loop, $('HTTP Request').all(0, runIndex) reads a particular run; the runIndex parameter is in the reference-previous-nodes docs. The done output is simpler and covers most cases.

Mistakes to avoid

Mistake	Result	Fix
Loop around nodes that already iterate	Same result, slower, harder to read	Remove the loop
Last node not wired back	Only the first batch runs	Connect it to Loop Over Items
Final steps on the loop output	They run once per batch	Move them to done
Reset without exit condition	Execution never ends	If node with a hard stop
Huge batches into Code nodes	Memory pressure	Smaller Batch Size

On n8n Cloud, executions also have a maximum duration per plan, so a long rate-limited loop over thousands of items may need to be split across executions, for example by a scheduled workflow that processes the next chunk each run.

Coming from Pipedream

Pipedream workflows had no loop operator; the control-flow docs still list looping as "coming soon" (Pipedream control flow). Loops lived in code steps: for (const row of rows) await axios(...). In n8n you usually split that step: the list becomes items, the API call becomes an HTTP Request node that runs per item, and Loop Over Items appears only if the API needs batching.

When our converter wraps a Pipedream code step, its loop stays inside the Code node. Plain JavaScript loops keep working. axios and fetch calls go through a shim built on a helper n8n doesn't document for the Code node, so test them; loops that use other npm packages don't run on n8n Cloud and need self-hosted n8n or a rewrite. The report lists those steps so you can decide which to split. Check a step with the code step checker, or get the report for your export in the converter. The report and 1 workflow are free. Full export: $3 per workflow, $19 minimum — coming soon.

Not affiliated with Pipedream or n8n.