Handle Errors and Retries Without Sending Things Twice

Every workflow that runs often will fail sometimes. An API times out, a login expires, or a service limits your requests. This lesson adds three layers of protection to the project: retries, error paths, and an alert.

What You'll Learn

• Which errors to retry and which to stop on
• How to set retries and error paths in n8n
• How to build one alert workflow for all your workflows
• How to avoid duplicate emails and records after a retry

Sort Errors First

Retrying does not fix every error. It helps only when the next attempt can succeed.

Layer 1: Retry on the Node

Open a node, go to its Settings tab and turn on Retry On Fail. Two more settings appear:

• Max Tries: how many attempts n8n makes.
• Wait Between Tries (ms): the pause between attempts. 1000 means one second.

For an AI model or an API call, start with three tries and a wait of a few seconds. If the service limits your requests, a longer wait helps more than extra tries.

Layer 2: Choose What Happens on Failure

In the same Settings tab, On Error has three options:

• Stop Workflow: the run ends here. This is the default choice for steps that must succeed.
• Continue: the run goes on using the last valid data. Use this rarely, because it can hide problems.
• Continue (using error output): the node gets a second output for failed items, so you can connect them to their own path.

For the project, use the error output on the customer lookup. If the lookup fails for one message, that message goes to a person and the others keep moving.

Test how retries and the error output work together on your n8n version. Some users have reported failed items going to the error output without being retried. Force a failure, then look at the run.

You can also create failures on purpose. The Stop And Error node stops the run with your own message. For example, add an IF node that checks whether the AI summary is empty. If it is, go to Stop And Error with the message "AI returned no summary".

Layer 3: One Alert Workflow

When a run fails at 3 a.m., someone needs to know. In n8n, this is an error workflow.

To set it up:

1. Create a new workflow with the Error Trigger node first.
2. Add a message node, such as Gmail or Slack.
3. Put these values in the message: {{ $json.workflow.name }}, {{ $json.execution.lastNodeExecuted }}, {{ $json.execution.error.message }} and {{ $json.execution.url }}.
4. Open your main workflow's settings and choose this workflow in the Error workflow field.

One error workflow can serve all your workflows. If the failure happens in the trigger node of the main workflow, n8n sends less information, so test both cases. Note that the execution link appears only if the run was saved, so keep failed runs in your execution settings.

The Danger of Retries: Doing Things Twice

Here is a common trap. Your workflow sends an email. The email service sends it, but the reply times out. n8n sees a failure and retries. The customer gets two emails.

Follow these rules:

• Retry reads freely. Looking up a record twice causes no harm.
• Be careful when retrying writes. Sending, charging and creating records can happen twice. Many builders leave Retry On Fail off on these nodes.
• Save a unique key. Use the message ID. Before you send, check a table to see if that ID was already handled. After you send, write the ID to the table.
• Put the risky step last, so a failure earlier in the run cannot repeat it.

The unique key idea has a technical name: idempotency. It means running a step twice has the same result as running it once. You will build the table for this in the memory lesson. There, the row goes in at the start of the run and its status changes to sent after the send, so one table does both jobs.

In Make and Zapier

Make attaches an error handler route to a module. It has five handlers:

Handler	What it does
Skip	Ignores the error and continues with the remaining data
Retry	Saves an incomplete execution to retry later, automatically or by hand
Resume	Uses a substitute value and continues
Commit	Stops and keeps the changes made so far
Rollback	Stops and reverts changes where the app supports it

Older guides call the Retry handler "Break".

Zapier has an error handler on paid plans. Open the three-dot menu on a step and choose Add error handler. The Zap splits into a success path and an error path. Once you publish a Zap with an error handler, Autoreplay turns off for that Zap, so plan your own recovery in the error path.

For patterns such as fallback models and partial results, see the error handling module in Prompt Chaining and Workflows.

Key Takeaways

• Retry temporary errors. Stop and alert on permanent ones. Route bad data to a person.
• In n8n, use Retry On Fail and the On Error setting on each node.
• One Error Trigger workflow can alert you about all your workflows.
• Retrying a write can send or create things twice.
• Save a unique ID and check it before any action that must happen only once.