n8n Split In Batches Node Explained: Process Large Datasets Without Timeouts (2025)

If your n8n workflow times out, hits API rate limits, or crashes when you feed it thousands of records, the fix is almost always the same: stop processing everything at once and start batching. The Loop Over Items node — still widely known by its old name, Split In Batches — lets you process large datasets in controlled chunks so you never blow past a memory ceiling or an API quota. This guide explains exactly how batching works, how to wire the loop-back correctly, how to tune batch size, and how to combine it with the Wait node to respect rate limits.

What the Split In Batches (Loop Over Items) node actually does

In n8n, most nodes run once per incoming item automatically. That's fine for a handful of records, but it becomes a problem when you're pushing 500, 5,000, or 50,000 items through an external API in a single execution. You risk request throttling, provider timeouts, and ballooning memory usage because n8n holds the full dataset in the execution context.

The Loop Over Items node solves this by slicing the incoming items into smaller groups and releasing them one group at a time. On each pass it emits a single batch through its loop output, waits for that branch to finish, then comes back for the next batch. When there's nothing left, it releases everything through its done output. This turns one giant, fragile execution into many small, predictable ones.

The rename from "Split In Batches" to "Loop Over Items" reflects what the node is really for: it is n8n's primary looping construct. If you've seen older tutorials or community workflows reference "Split In Batches," it's the same node.

The two outputs: loop and done

This is the single most misunderstood part of the node, so it's worth being precise:

• loop — fires once per batch. Everything downstream of this output is your per-batch work: call an API, transform data, write to a database. The last node in this branch must connect back into the Loop Over Items node.
• done — fires exactly once, after every batch has been processed. Use this for finalization: send a summary, aggregate results, or trigger the next stage.

The critical wiring detail: the tail end of your loop branch loops back to the top of the node, not forward to the next step. That back-connection is what tells n8n "this batch is done, give me the next one." Forget it and the node processes a single batch and stops — one of the most common n8n bugs beginners hit.

A correct loop, step by step

1. A trigger or data source produces N items (e.g., 800 products from a database).
2. Loop Over Items receives all 800 and holds them.
3. Its loop output emits the first batch (say 20 items).
4. Your HTTP Request, AI, or transform nodes process those 20.
5. The final node in that branch connects back to Loop Over Items.
6. The node emits the next 20, and repeats until all 800 are consumed.
7. The done output fires once with the accumulated results.

Choosing the right batch size

Batch size is set on the node itself. A batch size of 1 processes items strictly one at a time — safest for strict rate limits, but slowest. Larger batches finish faster but increase the load on whatever you're calling and raise the chance of hitting a limit. There is no universal correct number; it depends on the downstream service.

Start conservative, watch for errors or 429 responses, then raise the size until you find the ceiling and back off. The goal is the largest batch that completes reliably without throttling.

Combining Loop Over Items with Wait to respect rate limits

Batching controls how many items go through per pass; it does not control how fast the passes happen. If an API allows, say, a limited number of requests per minute, you need to add spacing. Drop a Wait node inside the loop branch — after your API call, before the back-connection.

With a batch size of 1 and a Wait of a couple of seconds per pass, you get a clean, predictable request cadence that stays under most rate limits. If your batch size is larger, remember the Wait applies per batch, not per item, so calculate accordingly. For providers that return a Retry-After header, you can read it and feed a dynamic wait duration, though a fixed conservative delay is simpler and usually enough.

A note on error handling inside loops

By default, an error in one batch can abort the whole execution — losing progress on every batch already processed. Turn on Continue On Fail for the risky node (usually the HTTP Request), or wrap the loop logic so a single bad record doesn't kill the run. You can then collect failures and retry them in a second pass rather than restarting from zero.

Want a production-grade example of this pattern in action? The Bulk Product Description Generator (Shopify & WooCommerce) template loops over hundreds of products, generates a unique AI description for each, and writes them back — with batching and pacing already wired so you never hit an AI rate limit. Get the Bulk Product Description Generator template →

A real example: looping over hundreds of products

Bulk content generation is the textbook use case for this node. Imagine an e-commerce catalog with 600 products missing descriptions. Sending all 600 to an AI model at once is a non-starter — you'd hit concurrency limits, risk a timeout, and get an unusable blob of output.

Instead, the flow looks like this:

1. Fetch all products from Shopify or WooCommerce.
2. Loop Over Items with a small batch size (1–5).
3. Inside the loop: build a prompt from the product's title and attributes, call the AI node, then a short Wait.
4. Write the generated description back to the store via its API.
5. Connect back to the loop node to fetch the next batch.
6. On done: send a Slack or email summary — "600 descriptions updated."

This structure runs for as long as it needs, one manageable chunk at a time, and never trips the timeout that a single monolithic call would. It's the difference between a workflow that works on 10 test products and one that survives your full catalog.

Resetting the loop between runs

The Loop Over Items node keeps internal state about which batch it's on. In most standard executions this resets automatically. But in more complex setups — nested loops, or a loop you re-enter within the same execution — that state can carry over and cause the node to think it's already finished. The node exposes a Reset option to force it to start counting from the first batch again.

Use Reset when you have an outer loop that runs the inner loop multiple times, or when a sub-workflow is called repeatedly. If your second run mysteriously produces zero batches, a stale loop counter is the usual culprit — enabling Reset fixes it.

Common mistakes to avoid

• No back-connection. The loop branch must return to the node. Without it, only the first batch runs.
• Connecting downstream nodes to the wrong output. Per-batch work goes on loop; finalization goes on done. Swapping them silently breaks the logic.
• Batch size too large for the API. A batch of 200 against a strict rate limit guarantees 429s. Start small.
• Forgetting the Wait node. Batching alone won't slow request frequency; add Wait for rate-limited services.
• No error handling. One failed record shouldn't discard progress on hundreds of successful ones.
• Ignoring Reset in nested loops. Stale state makes the loop skip on the second pass.

Frequently Asked Questions

Is Split In Batches the same as Loop Over Items?

Yes. n8n renamed the Split In Batches node to Loop Over Items to make its purpose clearer. The behavior is identical — it's the same batching and looping node, and older workflows or tutorials referencing "Split In Batches" still apply.

Do I always need a Loop Over Items node to process multiple items?

No. Most n8n nodes already run once per item automatically, so for small datasets you don't need to loop explicitly. Reach for Loop Over Items when you must control batch size or pacing — typically to avoid API rate limits, timeouts, or heavy memory use on large datasets.

Why does my loop only run once?

Almost always because the last node in the loop branch isn't connected back to the Loop Over Items node. That back-connection is what requests the next batch. Add it, and confirm your per-batch work hangs off the loop output rather than done.

Ready to automate?

Skip the trial-and-error wiring and start from a workflow that already batches, paces, and writes back correctly. Get this template on Gumroad →