Most n8n nodes already loop. If you added a Loop Over Items node to make a workflow iterate, there is a good chance you added a node that does nothing but slow it down.
The single most common misunderstanding in n8n is that you need a loop to process multiple items. You almost never do. n8n’s execution model runs each node once per input item automatically, so a Google Sheets node receiving 200 items writes 200 rows without any loop construct at all.
The Loop Over Items node — still called Split In Batches in older workflows and half the tutorials — exists for the narrower set of cases where automatic iteration is not what you want.
Table of contents
- The default behaviour nobody explains first
- Reason one: rate limits
- Reason two: memory pressure
- Reason three: genuine sequential dependency
- Reason four: per-item error isolation
- A checklist before you add the node
- Running the workflows that need this
- How this fits the rest of the stack
- FAQ
The default behaviour nobody explains first
Connect a node that outputs 200 items to an HTTP Request node. The HTTP Request node fires 200 times. No loop, no configuration, no Code node. That is the engine working as designed.
This catches people from an imperative background, where iteration is something you write. In n8n, iteration is the substrate. A workflow is a description of what happens to an item, and the runtime applies it to every item it receives.
Which means the first question is not “how do I loop” but “why isn’t the default enough?”. There are real answers, and they are the next four sections. But if you cannot name one, delete the loop node and watch the workflow get simpler and faster.
Reason one: rate limits
The most legitimate use. An API allows 10 requests per second, your node has 500 items, and default behaviour fires all 500 as fast as the runtime can manage. You get a wall of 429s and a workflow that half-succeeded.
Loop Over Items with a batch size of 10, plus a Wait node inside the loop, converts the flood into a paced sequence:
- Loop Over Items, batch size 10
- HTTP Request (fires 10 times per iteration)
- Wait, 1 second
- Connect back to the Loop node’s input
Check whether you need this before building it, though. The HTTP Request node has a Batching option in its own settings that paces requests without any loop at all. One node with an option set beats four nodes wired in a ring.
Reason two: memory pressure
n8n holds the full item set in memory between nodes. For 10,000 items carrying binary attachments, that is a problem long before it is a rate-limit problem.
Batching keeps only a slice live at a time. Combined with writing results to durable storage inside the loop, it turns a workflow that dies at item 4,000 into one that finishes, and one that leaves 4,000 completed rows behind if it does die.
This is the pattern for PDF processing, image handling, and anything where a single item carries a large binary payload. Small batch sizes — 5 to 10 — are correct here even though they feel absurdly conservative.
Reason three: genuine sequential dependency
Sometimes item N+1 depends on the result of item N. Paginating an API where each response carries the cursor for the next call is the classic case, and no amount of automatic iteration helps because the input set does not exist yet.
This is a real loop: the Loop Over Items node, an IF node checking a termination condition, and a connection back to the loop input. The noItemsLeft output is what ends it cleanly.
Two things that bite here. Runaway loops with no termination condition will happily run until the execution timeout, so build the IF node before you build the body. And nested loops behave differently to what most people expect — the inner loop’s completion resets state that the outer loop was relying on, so test nested designs with tiny datasets before trusting them.
Reason four: per-item error isolation
By default, one failing item can take the whole execution down. When you are processing 500 records and record 237 has a malformed date, the useful outcome is 499 successes and one item in an error queue — not zero successes and a red execution.
Loop Over Items with the node’s error handling set to continue gives you that boundary. Each batch succeeds or fails on its own, and a failed batch routes down the error output to be logged, queued or retried while the loop keeps going.
The alternative — and often the better one — is setting On Error to Continue (using error output) on the specific node that can fail, which gets you the same isolation without a loop. Prefer that when the failure is localised to one node.
A checklist before you add the node
Run through these in order. If every answer is no, the loop is not needed:
- Is an external API rate-limiting you, and does the calling node lack its own batching option?
- Are items carrying binary payloads large enough to threaten memory?
- Does each iteration genuinely depend on the previous one’s output?
- Do you need per-batch error isolation that node-level error output cannot give you?
Loops are also the hardest part of a workflow to reason about six months later, and the most common cause of executions that run for an hour and then time out. They earn their place; they should not be the default reach.
Running the workflows that need this
The workflows that need real batching are the long ones — thousands of items, paced API calls, retries, a Wait node adding a second per iteration. They run for minutes, sometimes longer, and they need an instance that stays up and has memory headroom rather than a laptop that closes at six.
Self-hosting n8n for that means a server, a Postgres database behind it instead of the bundled SQLite, TLS, and an upgrade routine. On RunxBuild, n8n is a managed tool with its own plan ladder, environment variables in the dashboard, custom domains and runtime logs, with a managed Postgres available next to it on the same platform.
How this fits the rest of the stack
Most loop questions in n8n are really questions about the execution model, and the answer is usually to remove a node rather than add one. The cases that genuinely need batching tend to be the long-running workflows — and those are the ones where the instance size and the database behind it start to matter. The RunxBuild hosting calculator shows what an n8n instance plus a managed database comes to per month before you commit to the design.
Useful related references:
- The n8n Merge Node: Combining Two Streams Without Losing Items
- n8n vs Make: Where the Complexity Goes
- n8n Use Cases: What It Is Genuinely Good At, and What It Is Not
- Services on RunxBuild
FAQ
Do I need Loop Over Items to process multiple items in n8n?
No. Nodes iterate over every input item automatically, so a node receiving 200 items runs 200 times with no loop at all. Use Loop Over Items only for rate limiting, memory pressure, genuinely sequential dependencies, or per-batch error isolation.
What is the difference between Loop Over Items and Split In Batches?
They are the same node. Split In Batches was renamed to Loop Over Items, and the documentation lists both names. Older workflows and tutorials still use the original name, but there is no functional difference and nothing to migrate.
What batch size should I use?
It depends on the constraint. For rate limits, match the API’s allowance per interval. For memory pressure with binary payloads, 5 to 10. For plain JSON items, larger batches are fine — the batching is not buying you much there anyway.
Why does my loop only run once?
Usually because the last node in the loop body is not connected back to the Loop Over Items node’s input. Without that return edge the loop processes the first batch and the execution moves on. Check the wiring before changing any settings.
How do I stop a loop that will not terminate?
Use the noItemsLeft output for input-driven loops, and an explicit IF node checking a termination condition for cursor-driven ones. Build the exit condition before the loop body, and set an execution timeout on the workflow as a backstop.