I’m seeing a dangerous behavior with Loop Over Items in an autoposting workflow.
What I expected
Loop Over Items should:
Process exactly one item per iteration
Then move to the next item
So the HTTP request runs once per row
What actually happens
It does process one item but it keeps repeating the first item over and over, causing duplicate API calls.
In my case:
It kept re running the same first row (same post id inputs)
The HTTP POST node fired hundreds of times
It published many duplicate posts
Eventually the Threads API started rejecting requests due to rate limiting
My workflow (from the screenshot)
Loop Over Items → Google Sheets read row → Wait 60s → HTTP POST (Threads) → Update row → Wait 3s → back to loop
So the loop looks correct, and the waits are there to prevent rate limit issues. But the loop still repeats the first iteration again and again.
Why this is serious
This can easily spam real APIs and get users blocked because it looks like automation abuse, even though the workflow logic is fine.
Question
Is there a known issue where Loop Over Items can:
Repeat the first item
Not advance the internal index properly
Especially when Wait nodes or sheet update nodes are inside the loop
If this is expected behavior, what’s the correct pattern to guarantee “exactly once per item”?
I can share export + execution details if needed.
Thanks.
PS. Because of this issue I am getting some troubles and trynna fix over over again, i am using the latest stable version of n8n, and running on cloud, since i am paying and relying on n8n nodes it would be better it worked with no issues.
The behavior you are describing—where the loop runs repeatedly but processes the same “first item” every time—is almost certainly caused by an Expression Reference Error in your nodes. When you configure the HTTP Request or Google Sheets Update inside the loop, you must ensure your expressions reference the Loop Over Items node (e.g., {{ $node["Loop Over Items"].json.id }}) rather than the original source node (e.g., {{ $node["Google Sheets Read"].json.id }}). If you reference the source node directly, n8n will always pull the data from “Item 0” of that source, ignoring the loop’s current iteration completely.
To fix this, update your expressions to explicitly use the loop’s output. If the issue persists, switching to the Split In Batches pattern (Batch Size: 1) is a more robust alternative for rate-limited APIs like Threads, as it forces a strict “one-at-a-time” execution context that guarantees unique processing.
