N8n retry on fail

What n8n retry on fail does, and what it does not

n8n retry on fail is a per-node setting. When it is switched on, a node that throws an error is run again after a pause, up to a set number of attempts, before the step counts as failed. The n8n error-handling page cited in this article covers error workflows rather than this setting. Treat these mechanics as things to confirm in your own node settings: the maximum number of tries, the wait between them, and the nearby options for what happens on error, such as stopping or continuing.

The key limit is that a retry repeats the same request with the same input. It helps when the cause is temporary, such as a brief network fault, a timeout or a service that is momentarily overloaded. It cannot fix a wrong credential, a malformed payload, a missing record or a changed API contract. In those cases every attempt fails the same way, and retrying only delays the failure. Exact attempt and delay limits can change between n8n versions, so check them in your own instance before relying on them.

Which failures are worth retrying

Before enabling retries, ask whether a second attempt a few seconds later has a realistic chance of succeeding. Temporary conditions usually pass that test. Deterministic conditions do not. Sorting likely errors into these two groups is the most useful decision you can make, and the answer is specific to each node and each external service.

Rate limiting needs particular care. A short, fixed pause between attempts may still fall inside the provider's limit window, so every attempt can fail together. If a node regularly hits rate limits, longer waits, batching or fewer calls usually work better than more retries.

• Usually retry: timeouts, connection resets, temporary 5xx responses, brief service unavailability.
• Usually do not retry: authentication or permission errors, validation errors, 404s for missing records, schema or field mismatches.
• Retry with caution: rate-limit responses, and any node that writes data to another system.

The duplicate-write risk

The most serious side effect of retrying is duplication. A node that creates an invoice, sends an email or posts a message may succeed on the remote side but still report an error, for example because the response timed out. n8n sees a failure and runs the node again, and the external system now holds two records or the customer gets two messages.

For any node that changes data elsewhere, check whether the target supports an idempotency key or an upsert, or add a lookup step before the write so a repeat attempt can detect existing work. If none of these is possible, it may be safer to leave retries off for that node and handle failure through an alert and a controlled manual recovery. Whatever you build should respect the same access controls and data-protection rules as the rest of your systems; a retry should never be a route around them.

Pairing retries with error workflows and alerts

Retries handle the expected, short-lived failures. Everything else needs to reach a person. The n8n documentation describes error workflows: a separate workflow that starts with an Error Trigger node and runs if an execution of the linked workflow fails. It receives details such as the workflow, the failed node and the error message, which you can route to a team channel, a ticket or an on-call tool. The documentation also describes the Stop And Error node, which lets you deliberately fail an execution when your own checks find bad data.

Two interactions are worth checking. Because the documentation ties the error workflow to a failed execution, it follows that a node set to continue on error may never trigger it, since the execution as a whole may not fail; this is an inference to confirm in your own instance. Retries also delay the signal: an alert can only arrive after the final attempt fails. Whether earlier attempts are visible in your execution history is something to verify rather than assume. The dependable proof that alerting works is to force a failure on purpose, for example with a Stop And Error node, and confirm the alert arrives with enough context to act.

Worked example: a nightly CRM sync

Example (hypothetical): a workflow runs nightly, reads new orders from a database, calls a CRM API to create contacts, then posts a summary to a chat channel. The database read occasionally times out, the CRM sometimes returns temporary 503 responses, and the chat post rarely fails.

A reasonable setup would enable retries on the database read, because a repeated read changes nothing. For the CRM step, the team would first add a search-by-email lookup so the create call becomes safe to repeat, and only then enable a small number of retries with a pause long enough for the service to recover. The chat post could be set to continue on error, because a missing summary should not mark the whole sync as failed. Finally, an error workflow would send the failed node name, error message and execution link to the operations channel, and the team would check it by deliberately forcing a failure and confirming the alert arrives.

• Read-only steps: retry freely.
• Write steps: make them safe to repeat before enabling retries.
• Non-critical notifications: continue on error, but still log the failure.
• Every workflow: link an error workflow and test it with a deliberate failure.

Decision checklist and how monitoring fits

Use this checklist before switching on retries for any node: is the likely failure temporary; is the node read-only or safe to repeat; is the pause long enough for the dependency to recover; will a final failure reach an error workflow; and will someone be told, with enough context to act? If any answer is no, fix that gap first. After each incident, revisit the settings: a node that needs retries every night is signalling a design or capacity problem rather than bad luck.

A dedicated monitoring layer can support early detection and diagnosis. Datvero is designed to watch n8n workflows and turn failures into actionable alerts with incident tracking, so recovery and follow-up do not depend on someone spotting a chat message. Its reach is bounded by the signals a team configures: monitoring can shorten the time before a failure is noticed, but it does not guarantee outcomes or catch every silent failure, and reliability still depends on how each team configures its platform and runs its operating process.