October 6, 2026

n8n Workflow Runs Twice? How to Fix Duplicate Executions (2026)

The one-paragraph version

n8n workflows run twice for four common reasons: (1) the webhook sender retried because n8n didn't respond fast enough, (2) you have two triggers (or two active copies) of the same workflow, (3) a scheduled trigger overlaps because the previous run hasn't finished, and (4) the source system genuinely sent two events. The fixes, in order: make your webhook respond immediately and process async, check for duplicate active workflows, turn on concurrency guards, and add idempotency keys so duplicates collapse harmlessly. Details below.

First: figure out which cause you have

Open the workflow's Executions list and look at the two runs:

• Same trigger data, seconds apart, one shows a timeout or 504 upstream? → Cause 1 (sender retry).
• Different execution sources or identical runs at exactly the trigger interval? → Cause 2 (duplicate trigger/workflow).
• Runs overlap in time, long-running workflow on a schedule? → Cause 3 (scheduler overlap).
• Two different event IDs / payloads from the source? → Cause 4 (genuinely two events; not n8n's fault).

Diagnose first. The fixes below match these four cases.

Cause 1: The sender retried the webhook

Most APIs retry a webhook POST if they don't get a 2xx response quickly (Stripe: up to ~72 hours of retries; Shopify: retries for 48 hours). If your n8n workflow takes 30 seconds to finish and the sender's timeout is 10 seconds, the sender assumes failure and sends the event again — even though your workflow processed it.

Fix: respond immediately, process async.

1. In your Webhook node, set Respond to "Immediately" (respond with 200 before the workflow finishes) instead of "When Last Node Finishes".
2. Do the slow work (database writes, AI calls, emails) after the response. The workflow keeps running; the sender is already satisfied.

This single change fixes the majority of "runs twice" complaints with webhooks.

Cause 2: Two triggers or two active workflows

Common variants:

• The same workflow is active twice — e.g., imported a duplicate, or the same workflow exists in two n8n instances/projects sharing one webhook URL.
• A workflow has both a Schedule trigger and a Webhook trigger for the same event.
• You clicked "test" and then the production trigger also fired.

Fix: search your workflows for the same webhook path or the same schedule. In n8n, go to Workflows → search by name fragment; check the Executions tab's "started by" to see whether runs came from the trigger or a manual test. Deactivate the duplicate.

Cause 3: Scheduled runs overlap

If a workflow runs every 5 minutes but takes 8 minutes to finish, n8n starts the next run before the previous one ends. Two runs now process the same data window — same records, double side effects (double emails, double database writes).

Fix options (pick one):

• Longer interval. If the work takes 8 minutes, don't schedule it every 5. Simplest fix, boring, correct.
• Concurrency guard. At the start of the workflow, check a flag (a row in Postgres/Google Sheets, or n8n's static data) that says "run in progress"; if set, stop. Clear it at the end. Use a try/catch-style pattern so the flag clears even on errors — a stuck flag means the workflow never runs again, which is worse than duplicates.
• Split the work. Move the slow part to a sub-workflow and have the scheduler just enqueue items.

Cause 4: The source sent two events (not your bug)

Some systems legitimately emit duplicates: a user double-clicks submit, a payment gateway sends both payment_succeeded and charge_succeeded, a form fires on page-load and on submit.

Fix: idempotency. Before doing anything with side effects, check whether you've already processed this event:

1. Extract a stable ID from the payload (Stripe: event.id; most webhooks include one).
2. Look it up in a Data Store / database table of processed IDs.
3. If it's there → stop the workflow. If not → record it and continue.

This is the only fix that works even when the duplicate comes from outside n8n entirely, so many teams add it as belt-and-braces alongside fixes 1–3.

Quick checklist

• [ ] Webhook node responds Immediately, not after completion
• [ ] No duplicate active workflow with the same webhook path/schedule
• [ ] Schedule interval > worst-case run duration (or a concurrency guard)
• [ ] Idempotency check on the sender's event ID before any side effect

Work through this list top to bottom and duplicate executions disappear in nearly every case I've seen.

Tested against n8n (self-hosted) as of October 2026. Webhook retry behavior cited for Stripe/Shopify — verify against your sender's docs, since retry policies change.

← Back to all field notes