Set n8n's Merge node to Combine by Position with two input branches of different lengths, and the node won't throw an error. It won't flag anything in the execution log either. It pairs items up by their index — item 0 with item 0, item 1 with item 1 — and whatever's left over on the longer branch just doesn't make it into the output. No red node. No warning. The workflow finishes exactly the way it finishes when everything went right.
What combine by position actually compares
Position mode is built for a specific shape of workflow: you've split a dataset into two parallel branches, each one does its own processing, and you need to stitch the results back together in the same order they left. Item 1 from branch A pairs with item 1 from branch B, and so on. It's a simple model, and it works exactly as advertised when both branches come back the same length.
The trouble starts when they don't. Say a lead-scoring workflow splits 40 leads into two branches — one enriches contact data, the other runs a disqualification filter that occasionally returns nothing for a given lead. Branch A comes back with 40 items. Branch B comes back with 37. Combine by Position pairs up the first 37 on each side. The last three leads from branch A, the ones with no index match on branch B, are just gone.
Why a quiet drop is worse than a loud failure
A node that errors out gets looked at — a red icon, maybe a Slack alert if you've wired one up, a reason to open the execution and see what happened. A Merge node that returns 37 items instead of 40 looks, to n8n, like a completed run. Nothing in the execution history distinguishes "merged everything" from "merged most of it." The item count is the only tell, and nobody checks item counts on a workflow that already looks done.
A dropped row and a processed row look identical in n8n's execution log. The only thing separating them is a count most people never think to check.
That's a rough failure mode for anything with real consequences downstream — an invoice run, a CRM import, a reconciliation job. You don't find out when the workflow runs. You find out a week later when someone asks why three leads never got a follow-up, and now you're combing through execution history trying to reconstruct what actually happened against what the dashboard claims happened.
The fix, and the one thing it doesn't fix
n8n's Merge node has a setting for exactly this, off by default: Include unpaired items. Turn it on and the node keeps everything that didn't find a match on the other branch instead of discarding it, tagged as unpaired in the output. In the lead-scoring example, you'd get your 37 paired items plus the 3 leftover leads from branch A, ready to route to a retry step or a manual-review queue instead of disappearing.
That's the right move when a length mismatch is expected — branches that legitimately produce different counts and need somewhere to put the leftovers. It's the wrong move when the mismatch is actually a symptom of something broken upstream. If branch B is supposed to return one item per input and it's quietly losing three out of forty, flipping on Include unpaired items just makes the Merge node survive the symptom. It won't tell you why branch B lost three items — a filter that's too aggressive, an API call failing without raising its own error, a loop node that didn't wait for every branch to finish.
So the actual question, before touching any setting on the Merge node: is this count mismatch expected, or is it evidence something upstream is already failing quietly? Answer that first. The setting only fixes the first case.
Catching it before it costs you anything
This doesn't need a new monitoring system. Right after the Merge node, add an IF node (or a Code node if you want more detail in the alert) that compares the merged output count against what each branch sent in, and routes to Slack or email when they don't match. Five minutes of setup turns a silent loss into something you hear about the same afternoon instead of the same quarter.
It's the same instinct behind catching a workflow that runs green and does nothing — green in n8n means the run didn't crash, not that it did what you expected. The Merge node is just one more place that distinction quietly costs you data instead of announcing itself.
If you're running n8n automations that merge data from more than one branch — lead enrichment, multi-source reporting, anything stitching parallel API calls back together — it's worth five minutes checking every Merge node you have in production for this setting. Automation audits like that are usually the first thing we do before touching anything new on a client's existing workflows.
— Cole
Sources
- n8n docs — Merge node reference, Combine mode and the Include unpaired items option: docs.n8n.io