Debugging Nested Loop Explosions in n8n: Why 2,000 Items Became 21,000

When an outer loop with a batch size and an inner loop with its own batch settings interact, it's easy to inadvertently multiply items by appending or merging arrays instead of replacing them. Common culprits: using nodes that return arrays and then feeding them into a SplitInBatches or Loop node without clearing state, merging outputs incorrectly, or having a Function node that pushes into the same output array across iterations.

Start debugging by simplifying: reproduce the issue with a stripped-down workflow that only creates the outer and inner loops and a logger node to capture payload shapes between steps. Check whether nodes are emitting single-item objects or arrays; inspect whether the Loop node is configured to accumulate results. Pay attention to options like "Continue on Fail," or custom code that concatenates outputs. If you must process nested collections, consider flattening or using explicit mapping functions to avoid implicit accumulation.

For operations teams, this issue affects cost, throughput and SLA compliance. Protect production systems with limits on maximum output size, resource-based throttles, and monitoring that alerts on unexpected spikes in items or CPU. Where possible, refactor nested loops into streaming or pagination patterns and centralize array handling in a single Function node to reduce stateful surprises. These steps minimize both performance risk and debugging time when workflows scale.