Errors, Retries and Error Workflows

Three levels of defence

First, each node has Retry On Fail with a wait between tries, good for temporary network or rate-limit errors. Second, On Error: Continue (or the error output) lets the workflow handle a failed item instead of stopping the whole run. Third, a separate error workflow starting with an Error Trigger node runs whenever a workflow fails, so you can send an alert with the workflow name, the failed node and a link to the execution.

Expect failure, limit damage

Real workflows meet bad data, timeouts and malicious input. Plan for each from the start.

Backoff schedule

A growing wait gives a struggling service time to recover. This ran in Node.js: delays double up to a 30-second cap. n8n's retry setting uses a fixed wait, so for backoff add a Wait node in a loop or use a Code node to compute the delay.

const delays = n => Array.from({ length: n }, (_, i) => Math.min(30, 2 ** i));
console.log(JSON.stringify(delays(6)));

Output:

[1,2,4,8,16,30]

Retry only safe actions

Retrying "send email" or "create invoice" can duplicate the effect if the first attempt actually succeeded. Use idempotency keys where the API supports them, or check for an existing record before creating one.

Quick check: What starts an n8n error workflow?

• A Manual Trigger node
• A Merge node
• A Schedule Trigger only
• An Error Trigger node when another workflow fails