How to Stop Duplicate Executions in n8n (2026)

The first instinct is that n8n glitched. Usually it didn't. There are four causes and only one of them lives inside n8n:

1. The sender retried.Webhook delivery is at-least-once by design. Stripe, GitHub, Shopify, your CRM — if they don't get a fast 2xx they assume the delivery failed and send the same event again. Your workflow ran perfectly the first time. The sender just never heard about it.

2. You told it to retry. Retry On Fail is a per-node setting and it is genuinely useful, right up until you put it on a node that creates something. A flaky API call that times out after the record was already written, retried three times, is three records.

3. The upstream system emitted it twice.Double-clicked submit buttons, a form embedded on two pages, a sync job that replays yesterday's events. This one has nothing to do with your automation stack at all.

4. The webhook got registered twice. This is the rare genuine n8n case, and it has an unmistakable signature: two executions of the same payload landing within tens of milliseconds of each other, far too close for a network retry. Community reports put the gap in the 30–70ms range. Deleting and recreating the trigger usually clears it.

Before you build anything, check one setting. The Webhook node gives you three response modes: Immediately, which fires back “Workflow got started” the moment the request lands; When Last Node Finishes, which holds the connection open for the entire run; and Using ‘Respond to Webhook’ Node, which puts the timing in your hands.

The default of holding the connection is where a huge share of duplicate executions are born. Your workflow calls an AI model, waits on a slow CRM, writes three rows, and takes eleven seconds. The sender gave up at five. It got a timeout, marked the delivery failed, and queued a retry — while your first run was still happily finishing. Nothing errored. You just built a duplicate factory.

Switch to Immediately, or respond early with a Respond to Webhook node and do the slow work afterwards. It costs you nothing and it removes the single most common cause. It does not, however, make your workflow safe — it only makes retries rarer. For that you need a gate.

Every forum thread on this eventually points at the Remove Duplicates node, specifically its Remove Items Processed in Previous Executions mode. It keeps a history of keys it has seen and drops anything it recognises. That sounds exactly like what you want, and for a low-volume workflow that fires once a minute it is fine.

It falls over in two specific ways, and both of them show up precisely when duplicates matter most.

It checks, then it writes — and something can happen in between. Read the history, decide the key is new, record the key, continue. Four steps, not one. If the same event is being processed twice at the same moment, both executions can read the history before either has written to it, and both conclude they are the original. This is the textbook check-then-act race, and it is not a hypothetical: it is the normal state of affairs the second you run queue mode with multiple workers, where two workers on two machines are pulling from the same job queue. The docs make no atomicity claim for this node, and you should not read one into it.

The history is a rolling window.History Size defaults to 10,000 items. On a workflow doing real volume, a retry that arrives an hour late can find that its key has already aged out — and an evicted key is a key that looks brand new. You can raise the ceiling, but you are tuning a cache to do a database's job.

It is a convenience filter. Treat it as one.

The whole trick is to stop asking “have I seen this before?” and start asking “did I just win the right to process this?” — because the second question can be answered by the database in a single operation, and single operations cannot race.

Step 1: pick a key that survives the retry. Use whatever identifier the sender already stamps on the event — event.id from Stripe, a delivery id, a message id, an order number. The retry carries the same value; that is the entire mechanism. Do not use a timestamp, a UUID you generate in a Set node, or the n8n execution id. All three change on every attempt, and every duplicate will walk straight through your gate. If the payload truly has no stable id, hash a canonical subset of the meaningful fields and be deliberate about which ones you include.

Step 2: claim it in one write. Create the table once:

CREATE TABLE idempotency_keys (
  key         text PRIMARY KEY,
  workflow    text NOT NULL,
  status      text NOT NULL DEFAULT 'in_progress',
  created_at  timestamptz NOT NULL DEFAULT now()
);

Then make the very first Postgres node in your workflow run this, and nothing else:

INSERT INTO idempotency_keys (key, workflow)
VALUES ($1, $2)
ON CONFLICT (key) DO NOTHING
RETURNING key;

One row back means you are the original. Zero rows means someone else already claimed it. That is the whole gate. The uniqueness check and the claim are the same statement, executed under the same lock, so there is no window for a second execution to slip through — no matter how many workers you run or how close together the retries land. Postgres's ON CONFLICT clause exists for exactly this.

If you would rather use Redis, the equivalent is one command:

SET idem:{workflow}:{event_id} 1 NX EX 86400
# OK   -> you claimed it, proceed
# nil  -> duplicate, stop

NX is the atomic part and EX handles expiry for free. I compared the two stores for agent memory in Postgres vs Redis for n8n agent memory, and the reasoning here is the same: Postgres if you want the record to persist and be queryable, Redis if you want speed and automatic cleanup.

Step 3: put an IF node right behind it, and put both in front of everything else. Empty result goes to a dead end that responds 200 and stops. This is the part people get wrong even when the SQL is perfect — the gate has to sit before the first node that writes, charges, emails, or posts. A gate in the middle of a workflow protects the second half and leaves the first half wide open.

Here is the trap in the naive version. You claim the key at node one. At node six the API you're calling throws a 503 and the execution dies. The sender does the right thing and retries — and your gate, working exactly as designed, rejects it, because the key is already claimed.

You have not fixed duplicates. You have converted them into silent data loss, which is strictly worse, because a duplicate row is visible and a missing one is not.

The fix is to treat the claim as two phases. Insert with status = 'in_progress', and on the final node of the happy path update it to done. Then the gate's decision has three branches instead of two:

no row          -> first attempt, proceed
status = done   -> real duplicate, stop
status = in_progress
  and older than 10 min -> stale claim, take it over
  and recent            -> a twin is running, stop

Then wire an error workflow that deletes the claim whenever the run fails. Between the error handler and the staleness timeout, a crashed execution always frees its own key, and the retry that follows does the work instead of being silently swallowed.

That timeout is a real judgement call, not a default to copy. It has to be longer than your slowest legitimate run and shorter than your patience for a stuck record. Ten minutes suits webhook workflows that finish in seconds. An agent workflow that legitimately runs for four minutes needs a much wider window.

That last row is worth a second look, because it is the cheapest option on the list. If your workflow's only side effect is inserting one record, you do not need a separate gate at all — put a UNIQUE constraint on the natural key of the target table and let the second insert fail. The database is already the arbiter. Adding a gate in front of it is ceremony.

My instance runs 179 workflows, 61 of them active, at roughly 5,600 executions a month, and the median execution finishes in under a second. The gate adds one indexed write to a Postgres instance sitting on the same box — call it a couple of milliseconds against a run measured in hundreds.

The honest cost is not latency, it is discipline. Every workflow that touches money, sends a message, or writes to a system of record needs the gate, and the day you add a new one is the day you have to remember to add it again. I keep a template workflow with the gate already wired so it is a copy rather than a decision, which pairs well with keeping the definitions in version control without paying for Enterprise.

One more thing worth knowing, especially if you are near a plan limit: a rejected duplicate is still a billed execution. The gate stops the damage, not the count. If duplicates are a meaningful slice of your volume, that is a real line item — and I worked through where those limits actually bite in n8n Cloud vs self-hosted. The cheaper fix for a noisy sender is usually to stop the retries at the edge rather than inside n8n, which is the same layer where Cloudflare Access sits in front of your webhooks.