n8n reliability guide

Prevent duplicate n8n executions

Retries are useful. Duplicate side effects are not. This guide shows how to make webhook, queue and manual rerun paths safe when the same business event can reach n8n more than once.

Where duplicates come from

Webhook replay. A sender retries because it did not receive a timely acknowledgement.
Manual retry. A failed execution is retried with the original or currently saved workflow.
Queue replay. A worker restarts after a partial write and processes the event again.
Polling overlap. Two runs discover the same upstream record before either marks it processed.
Timeout ambiguity. The destination succeeds, but n8n sees a timeout and retries.

The idempotency pattern

Choose a stable event key before the first state-changing node. Prefer an upstream event ID, order ID, ticket ID or a deterministic hash of immutable fields. Store that key in a durable system that can answer whether the side effect already completed.

A simple check-then-write can still race if two executions run together. Prefer an atomic insert, unique constraint, transactional write, or a destination API that supports idempotency keys.

Classify nodes by side effect

Read-only: lookup, fetch, transform. Usually safe to repeat.
Conditionally safe: update or upsert keyed by a stable identifier. Verify destination semantics.
High risk: create a new external record, send a message, append data, publish content. Require dedupe or an idempotency key.

Retry without creating a second outcome

n8n supports retrying failed executions from execution history. Treat a retry as a replay of business intent, not proof that the first attempt produced no external effect. Before retrying a state-changing step, verify whether the destination already contains the intended result.

Official n8n docs: retry failed executions. For production hardening, also review the official security audit.

Failure tests worth running

Send the identical webhook twice within one second.
Force a timeout after the destination accepts the request.
Restart the worker between side effect and local completion marker.
Retry a failed execution after confirming the destination succeeded.
Run two pollers against the same unprocessed record.

Minimum evidence for a safe workflow

Keep the event key, execution ID, destination result ID, timestamps and retry decision. If a duplicate is suppressed, log why.

Want this checked on a real workflow?

Start with the free deterministic preflight. For one workflow, the bounded audit checks retry paths, duplicate actions, secrets, failure handling and recovery evidence.

1-workflow audit — $49Toolkit — $29Free preflight