Before You Retry an n8n Workflow: Check for Duplicate Actions

A failed workflow does not establish that every external action failed. Before retrying a workflow that creates a record or sends a message, identify what has already happened and what remains uncertain.

Classify the external outcome first

Outcome	Decision to make before retrying
Confirmed success	Reuse the existing result; avoid repeating the action
Confirmed rejection	Correct the cause and check the endpoint’s retry rules
Unknown outcome	Reconcile with the external system before another write

Keep the event identifier, intended action, external record or request identifier, evidence checked and recovery owner. A local failure status is one piece of evidence, not proof that the receiving service rolled back.

n8n’s rate-limit guidance describes Retry On Fail and a configurable pause. That controls retry timing; it does not establish idempotency. The HTTP Request timeout description concerns waiting for the initial response. It does not promise cancellation of an action already accepted by the other service.

Check the API’s idempotency contract

For an endpoint with idempotency support, check key scope, retention window, payload matching, concurrent requests and which outcomes are remembered. Reuse a key only according to that endpoint’s current rules.

Stripe’s API v1 is one documented example: after endpoint execution starts, the first result is saved, including a 500 response. Keys may be removed after at least 24 hours; reuse after removal can start a new request. Validation failures and concurrent conflicts can fall outside saved results. The same page distinguishes API v2. Do not transfer these rules to a CRM, email API or every Stripe API.

A local event ledger should also handle concurrent processing and the gap between external success and local recording. A lookup followed by a write is not automatically atomic. Neither a spreadsheet ledger nor a retry setting alone proves exactly-once external effects.

Reconcile before restarting a whole run

In a fictional example, event E204 creates ticket T88, then a notification step fails. First check whether T88 exists. Record its confirmed identifier and decide how to complete the notification without creating another ticket. These identifiers do not describe a real execution.

n8n’s debugging feature can copy a past execution into the editor and pin its input. Availability depends on the edition and saved execution data. Copying input is not proof that rerunning external writes is safe.

Plan tests without touching real recipients

Use authorised sandbox systems and dummy events to plan tests for repeated events, concurrent requests, a timeout after acceptance, a failed local ledger write and partial workflow success. Verify both the external records and local evidence. This article proposes that plan; it contains no results from a completed test.