Field note · found 26 October 2026
n8n Merge node runs twice and sends a duplicate summary
An n8n Merge node in append mode can run twice in one execution: once when its first inputs are ready, and again when a slower branch finishes. Anything placed after it, such as a summary email, is then sent twice.
Test record: run by Fractional HQ on 26 October 2026 on a test n8n hosted on Railway, execution order v1. One execution, number 47805, showed the double run, and it was not repeated. n8n version not recorded. Not tested: the other Merge modes, execution order v0.
Symptom
On 26 October 2026 we were adding branches to our invoice reminder template on a test n8n hosted on Railway. The workflow sent its reminders, a separate branch handled the ones that failed, and both fed an append Merge node with the summary after it. In execution 47805 the summary went out twice. The workflow was on execution order v1.
The design had already passed a first review, and we only saw the second summary once we ran the branches.
Why it happens
What we saw is that the Merge node ran as soon as the inputs that were ready had arrived, and then ran a second time when the failure branch finished. We read the order in which the nodes executed from the execution data. We did not read the Merge node's source, so we cannot say whether this is intended for append mode.
The fix that held
We stopped using a Merge node as the gate for a summary or an alert. The summary is now written from the node that picks the invoices to chase, before anything is sent, and each failure branch sends its own alert once. Nothing downstream waits for two branches to arrive together any more, so there is nothing to fire twice.
The check we added to our own review is to run every branch once and read the order in which the nodes ran, since a green final status would not have shown the second summary.
A related trap from the same day
A Google Sheets node that fails on a batch returns one error item, and its paired item points at the first row whichever row caused the failure. Naming the failed rows from that pointer would blame the wrong invoice, so we report the whole batch as failed, or compare the ids that came back as saved with the ids we sent.
How we found it
Both were measured on the test instance on 26 October 2026, by running the branches with test data and reading the executions. Neither came from the documentation.
What we did not establish
We have one execution showing the double run, and we did not repeat it to see how often it happens. We did not test the other Merge modes, or execution order v0. We did not record the n8n version for that day's runs.
Written by Fractional HQ from its own runs. If your n8n behaves differently, email hello@fractionalhq.uk and we will correct the note.