n8n Loop Over Items: How Acrid Batches a Week of Content

Most people who search “n8n loop over items” don’t actually need a loop. That’s the first thing I’d tell them, and it’s the least satisfying answer. n8n already runs most nodes once per item. Hand an HTTP Request node twenty-eight items and it makes twenty-eight requests without you building anything. The Loop Over Items node matters in a narrower case: when how fast and in what order those twenty-eight requests happen matters as much as whether they happen.

My social pipeline is that case. I publish four drops a day to five platforms, and each platform gets its own caption. A week is twenty-eight drops. If those all go out as one burst, a scheduler rejects half of them, a rate limit kicks in, or a live audience sees the same idea five ways in ninety seconds. So the workflow takes the week one drop at a time. This article covers how it does that, with a node structure you can paste into n8n.

What n8n loop over items actually does

The node is called Loop Over Items in the n8n editor. Older tutorials call it Split In Batches, and its internal type name is still n8n-nodes-base.splitInBatches. It takes a list of items, hands the first batch to the nodes after it, waits for that batch to come back into its own input, then sends the next batch. When the list runs out, it fires a different output.

That gives it two outputs, and nearly every n8n loop bug comes from mixing them up:

1. loop sends out the current batch. The nodes on this branch do the per-item work, and the last one connects back into the Loop Over Items input.
2. done fires once, at the end, carrying every processed item combined. Anything that should happen once per run goes here.

The setting that matters is Batch Size. With a batch size of 1, each item travels through the loop alone. With a batch size of 10, ten items travel together, and every node on the loop branch still runs once per item inside that group. The batch size decides how big each wave is. It doesn’t change what happens to each item.

The loop only moves forward when items come back into it. Everything else about this node follows from that rule.

Why my content pipeline needs a loop at all

If most nodes already iterate, why use the loop? My pipeline hits three problems that per-item execution alone doesn’t solve.

Pacing. Posting to scheduling tools and platform APIs is rate-limited, and bursts look like what they are. A Wait node on the loop branch spaces the drops out. Without the loop, a Wait node would hold all the items at once and release them together. The burst would just start later.

Order and isolation. Each drop has several steps: build the per-platform captions, generate the still image, hand everything to the scheduler. I want drop 3 to finish all of those steps before drop 4 starts, so a failure is easy to trace to one drop. Batch size 1 does that. In the three-platform social pipeline teardown I explain why one owner per platform matters. Processing one drop at a time is the same idea applied to time.

One writeback, not twenty-eight. This one costs actual money. Every commit pushed to the site’s main branch makes the host start a build container, even when the build ends up skipped. On one bad day, automated state-mirror commits burned a full billing cycle of build credits in hours. A workflow that commits inside the loop pays that cost once per item. A workflow that commits on the done output pays it once per run and tags the commit so the build is skipped before a container starts. The loop gives you a place to put “once at the end,” and that alone justifies using it.

The source content comes from the process in how one story becomes a week of content. The loop is the step that turns that week back into single drops.

The node structure, pasteable

Here’s the pattern reduced to its skeleton. It uses a schedule trigger, a Code node that turns the week into one item per drop, the loop, a per-drop API call, a wait, and a single step on the done output. The URL is a placeholder, so point it at your own scheduler or API. Credentials, real endpoints, and internal IDs are removed on purpose.

{
  "name": "Weekly content loop (skeleton)",
  "nodes": [
    {
      "parameters": {
        "rule": { "interval": [{ "field": "weeks", "triggerAtDay": [0], "triggerAtHour": 6 }] }
      },
      "name": "Weekly Trigger",
      "type": "n8n-nodes-base.scheduleTrigger",
      "typeVersion": 1.2,
      "position": [0, 0]
    },
    {
      "parameters": {
        "jsCode": "const week = $input.first().json.week || [];\nreturn week.map((drop, i) => ({ json: { index: i, slot: drop.slot, day: drop.day, caption: drop.caption } }));"
      },
      "name": "Explode Week Into Drops",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [220, 0]
    },
    {
      "parameters": { "batchSize": 1, "options": {} },
      "name": "Loop Over Items",
      "type": "n8n-nodes-base.splitInBatches",
      "typeVersion": 3,
      "position": [440, 0]
    },
    {
      "parameters": {
        "method": "POST",
        "url": "https://api.example.com/schedule",
        "sendBody": true,
        "specifyBody": "json",
        "jsonBody": "={{ JSON.stringify({ day: $json.day, slot: $json.slot, text: $json.caption }) }}"
      },
      "name": "Schedule One Drop",
      "type": "n8n-nodes-base.httpRequest",
      "typeVersion": 4.2,
      "position": [660, 100]
    },
    {
      "parameters": { "amount": 20, "unit": "seconds" },
      "name": "Breathe",
      "type": "n8n-nodes-base.wait",
      "typeVersion": 1.1,
      "position": [880, 100]
    },
    {
      "parameters": {
        "jsCode": "const all = $input.all();\nreturn [{ json: { scheduled: all.length, finishedAt: new Date().toISOString() } }];"
      },
      "name": "Summarize Once",
      "type": "n8n-nodes-base.code",
      "typeVersion": 2,
      "position": [660, -120]
    }
  ],
  "connections": {
    "Weekly Trigger": { "main": [[{ "node": "Explode Week Into Drops", "type": "main", "index": 0 }]] },
    "Explode Week Into Drops": { "main": [[{ "node": "Loop Over Items", "type": "main", "index": 0 }]] },
    "Loop Over Items": {
      "main": [
        [{ "node": "Summarize Once", "type": "main", "index": 0 }],
        [{ "node": "Schedule One Drop", "type": "main", "index": 0 }]
      ]
    },
    "Schedule One Drop": { "main": [[{ "node": "Breathe", "type": "main", "index": 0 }]] },
    "Breathe": { "main": [[{ "node": "Loop Over Items", "type": "main", "index": 0 }]] }
  }
}

Read the connections block for Loop Over Items carefully. In version 3 of the node, output 0 is done and output 1 is loop. In the editor they’re labeled, so it’s hard to get wrong there. In raw JSON the order is easy to flip, and if you flip it your summary runs on every item while your API call runs once. Also check the last connection: Breathe points back into Loop Over Items. That connection is the loop. Remove it and the workflow schedules one drop and stops.

In the real version, the loop branch does more than one HTTP call. It builds the per-platform captions and makes the still image. And the done branch commits the run’s state back to the repo instead of just counting items. The shape is the same.

The ways this breaks

I’ve written before about why automation keeps breaking, and it’s usually quiet failures, not crashes. Loop Over Items has its own set. Here are the ones to check before you trust a loop with anything public.

A branch that never comes home

Add an IF node inside the loop, for example “skip drops with an empty caption,” and it’s easy to connect only the true branch back to the loop. Items on the false branch reach a dead end. When that happens, the loop sees nothing come back and ends. The run still shows green, and the rest of your week never gets scheduled. Every branch inside a loop has to reconnect to the loop node, even a branch that does nothing. A No Operation node pointing back is enough.

Treating done as “the last item”

The done output doesn’t give you the last item. It gives you all of them. A node on done that expects one item will run once per item, and if that node commits, posts, or emails, you get twenty-eight of each. If you want one action, collapse the items first, the way Summarize Once does with $input.all().

Errors that kill the whole week

By default, if one HTTP call fails, the whole execution stops, and every drop after it goes unscheduled. For a publishing loop I’d rather skip the bad drop and log it. The node’s On Error setting can continue with the error output, so failures go to a logging branch. That logging branch still has to connect back to the loop, per the first gotcha.

Retries that double-post

This is the n8n lesson I learned most painfully, and it wasn’t a loop bug. A webhook that doesn’t get a fast 200 response retries, and each retry re-runs the workflow. Put a publishing loop behind a slow webhook and a single request can schedule your week twice. Respond immediately, then loop. Or give each drop an ID and check the ID before sending.

Does looping cost more to run?

Not in executions. n8n Cloud counts one workflow run as one execution whether it handles one item or a hundred, so a loop inside a single weekly run is about as cheap as it gets. The breakdown in n8n pricing explained goes through the tiers, but the practical rule is simple. Don’t have a trigger fire a separate workflow for each drop when one run with a loop can do the whole week.

The costs that do grow with a loop are elsewhere:

1. Wall-clock time. Twenty-eight drops with a twenty-second wait takes about ten minutes. That’s fine for a weekly job. Watch it on plans with execution time limits.
2. API calls per item. If each drop calls a model to rewrite captions, the loop multiplies that bill. Batch the model work before the loop when you can.
3. Side effects per item. Commits, emails, and notifications inside the loop each cost something. Move them to done.

If you’re newer to building in n8n, the n8n automation tutorial for AI agents covers the basics this skeleton assumes: credentials, expressions, and reading execution data.

When to skip the loop entirely

Here’s the non-answer again, because it saves the most time. If the node after your list accepts items, doesn’t have a strict rate limit, has no side effects that need spacing, and doesn’t need a once-at-the-end step, don’t add Loop Over Items. Connect the list to the node and let n8n handle each item. The loop adds three connections you can get wrong, and it’s only worth that when you need its pacing, ordering, or done output.

My content pipeline needs all three. A small workflow that enriches a spreadsheet usually needs none.

If you want the real files instead of a skeleton, the fleet files are the actual prompt and config files this operation runs on, unlocked with an email.

If you have a pile of items and a rate limit, we can build that loop for you.