n8n check · retries
n8n Retries and Duplicate Side Effects
Retry is not inherently a bug. The engineering question is whether a repeated attempt is bounded, observable, and safe when the external system may have accepted the first request.
What is this risk?
n8n exposes retry and failure-handling settings for nodes and executions. A retry policy is one part of a design; it does not by itself create an idempotency guarantee for an external API.
This page treats retry safety as a relationship between transport behavior, the endpoint contract, duplicate-prevention signals, and the workflow’s recovery path.
Typical failure pattern
The request succeeded before the response timed out
- Webhook
- External API write succeeds
- Response times out or the connection is interrupted
- Workflow retries the write
- The downstream system receives the same business action again
Why it matters
- A missing retry policy can lose work during a transient failure, while an unsafe retry can repeat an irreversible action.
- The same workflow may combine HTTP mutation risk with a create-like database or CRM operation, so one replay can create more than one duplicate.
Auturance signals
WL002Mutating or dynamic HTTP calls have no retry policy
This is the current scanner signal associated with this check.
WL006Create/append operations may duplicate business data
This is the current scanner signal associated with this check.
What Auturance checks
- Flags mutating or dynamically configured HTTP Request nodes without an explicit retry policy.
- Flags create, insert, and append-like writes without a visible duplicate-prevention signal.
- Reports static evidence and leaves endpoint-specific retry safety for engineering review and testing.
What Auturance cannot determine
- It cannot see whether an external server accepted a request before a timeout or what response was lost.
- It cannot prove backoff, retry limits, rate-limit behavior, or the external API’s idempotency contract from the graph alone.
- Retry settings do not prove exactly-once delivery, atomic transactions, or safe replay.
How to reduce the risk
- Define which failures are retryable and bound attempts with appropriate backoff and observability.
- Use an idempotency key, stable business key, unique constraint, or upsert for replayable mutations.
- Test timeout-after-acceptance and partial-completion cases with the real downstream contract.
Related checks
Related resource
Frame the review with the workflow audit guide for the broader production-readiness review.
Related guide
See what your workflow reveals
Upload an authorized n8n export and review the static signals in its actual graph.