n8n · Help

n8n retry creates duplicate records or actions?

An n8n run failed after the target already processed its request? Reconcile business references and retry behaviour before repeating the action.

Source date: 5 November 2026Editorial team: KAN KAI WORKSEditorially updated:

Quick answer

An n8n retry can process the failed node's inputs again, including items already handled before the failure. A failed overall execution therefore does not prove that the destination created nothing. Before retrying, inspect the business reference, individual action status and available request IDs at the destination. Choose one controlled recovery path; a new execution ID alone does not prevent duplicate effects.

Source basis: Q2

Applies to
Applies to documented retries of failed n8n executions. Protection against repeated external actions depends on the destination API and workflow; sub-workflows require separate assessment.
How to verify the result
A harmless test covering a lost response and controlled retry produces the intended external action once per business reference, with original and retry outcomes reconciled.
Your first check

Does the destination already contain the affected operation?

A workflow fails even though the destination already contains the order, ticket or other record. After clicking Retry, the same business action appears twice. Your first task is to establish which individual action completed. A failed overall execution does not answer that question.

What the retry actually repeats

Current n8n documentation says that a retry resumes at the failed node and processes its saved inputs again. For a node with several inputs, those inputs can include items already processed before the failure. Retrying a failed sub-workflow starts that sub-workflow again. Q2 A public discussion raises the resulting risk of duplicate external effects; it does not establish a general data-loss defect. Q1

Check before starting another attempt

  1. Identify the business operation. Record the original execution, failed node, affected input item and a stable order or event reference. Add the IDs of any retries to the same investigation.
  2. Read the destination independently. Look up that reference and compare its timestamp, content and status. A matching completed operation argues against creating it again. An empty search result is insufficient when processing or indexing may still be delayed.
  3. Locate the failure boundary. Did the request leave n8n? Did a response return? Can the destination trace its request ID? Distinguish rejection before processing from a lost response and a failure to store the result afterwards.
  4. Choose one recovery path. Do not run the original execution, its retry and a copied manual execution in parallel. Assign a clear decision for each business operation: reconcile, wait or repeat under controlled conditions.

A suitable protection mechanism

Where the destination API supports idempotency, use a stable key for the business action, such as event, action type and record. A fresh execution ID changes between attempts and therefore does not identify the same action across retries. Check the provider's retention period and its treatment of changed request content as well.

Without that API feature, recovery requires a destination reconciliation process and potentially an atomic uniqueness constraint. A local “done” flag does not by itself close the gap between external success and storing the flag. Treat this as a design decision. Exercise success, lost response and repeat scenarios using a harmless test record before enabling automatic retries.

Information for a handover

Provide a redacted workflow section, n8n version, affected execution IDs, destination request IDs and a table linking each business reference to its intended and observed outcome. Keep credentials out of exports and screenshots.

Example: Three inputs, one failure, different destination states

Constructed diagnostic example: An imagined n8n node handles TEST-A, TEST-B and TEST-C, then fails while processing the third item. This is a test-planning scenario, not a real execution.

Inspect the destination before retrying
ReferenceAssumed findingQuestion
TEST-ARecord existsDoes its content match the intended result?
TEST-BRecord existsHas the action already completed?
TEST-CResponse missingRejected, still running or already processed?

Decision: A failed node does not imply that all external effects failed. Its retry processes the saved inputs again. Establish the existing destination state for A and B, and resolve C's uncertainty first. A new execution ID does not replace a stable business reference.

Prepare the retry path using neutral test data: repeated delivery of one operation keeps the same business identity. The technical protection depends on the destination. Searching before creating does not itself establish safety when attempts overlap.

Expected observation: Each input's destination effect can be identified even when the overall execution fails.

Success check: Following a controlled retry, each test reference has exactly the intended record. Verify content and other effects too. Do not independently restart both the original execution and its failed retry.

Technical references: n8n: View all executions / What a retry runs.

Frequently asked questions

Does a timeout prove that the destination did nothing?

No. The response can fail to arrive after the destination has accepted the action. Inspect its state before sending another write request.

Is retrying only the final node safe?

Only after checking that node's own effects and all its inputs. One node can issue several external operations, some of which may already have completed.

Help with this case

We can help isolate the affected process and prepare a controlled next step. Discuss case A0003 with KAN KAI WORKS.

Support with this issue

We investigate n8n using your error message, versions and a narrowly scoped example.

Describe your case →Related service: AI & automation

Sources

Sources checked on 5 November 2026. Individual reports do not establish general prevalence.