Error handling in n8n: retries, error workflows and alerts that stop silent failures

The most dangerous automation is one that broke last Tuesday and nobody noticed. Leads stopped reaching the CRM, invoices stopped syncing, and everyone assumed it was working because it always had. n8n has good tools to prevent this, but none of them are on by default.

We tested the patterns below on a self-hosted n8n 2.44.5 against a mock service we could switch on and off.

Layer 1: retry the things that fail briefly

APIs time out, rate-limit and have short outages. Most of those fix themselves within seconds.

On every node that calls another service (HTTP Request, CRM, email, sheets), open the node’s Settings and turn on:

• Retry On Fail
• Max. Tries: 3 is a sensible default
• Wait Between Tries (ms): 1,000–5,000 ms. Longer for APIs with rate limits.

In our test, a node with Max. Tries 3 called a failing service exactly three times before giving up, and called it once when the service was healthy.

Don’t retry steps that aren’t safe to repeat, such as “create invoice” on an API without duplicate protection. A retry after a timeout can create two. For those, search first, then create (as in our form-to-CRM workflow), or use the API’s idempotency or upsert option if it has one.

Layer 2: decide what happens when retries run out

Each node’s On Error setting has three options:

Error workflows: one alert for everything

An error workflow is a separate workflow that starts with the Error Trigger node. You set it in each workflow’s Settings → Error workflow, and one error workflow can serve many workflows. It receives details including the workflow name, the last node executed, the error message and, for saved executions, a link to the failed run.

A good error workflow posts to the channel your team actually watches (team chat, email or WhatsApp) with:

• which workflow failed, and at which step
• the error message
• the execution link
• what the person should do, for example “add this lead by hand”

The catch we confirmed

If a node uses Continue (using error output), the execution doesn’t fail. It takes the error branch and finishes. So the error workflow does not run. If your error branch doesn’t alert anyone, the failure is silent again. Rule: every error branch ends in an alert or a logged record someone reviews.

An older GitHub issue (reported on n8n 1.35.0) said retries were ignored when a Continue option was selected. In our test on 2.44.5, Retry On Fail and Continue (using error output) worked together: three attempts, then the error output fired with the error details.

Make bad data fail on purpose

Some problems don’t throw errors. An API returns an empty list, a required field is missing, a total is zero. Use an IF node to check for the bad case and send it to a Stop and Error node. That fails the execution deliberately, so your error workflow alerts you.

Layer 3: notice when nothing runs at all

Retries and error workflows only help when a workflow runs. They can’t tell you that:

• the webhook URL changed and your website is posting to the old one
• a schedule was switched off
• an app stopped sending events

Add a heartbeat check: a small scheduled workflow (daily or hourly) that looks for evidence of normal activity, such as “at least one new lead in the CRM in the last 24 hours” or “today’s order sync ran”. If the evidence is missing, it alerts you. Pick the check and the time window based on your normal volume, so it doesn’t cry wolf over a quiet weekend.

Keep the evidence

Alerts are only useful if you can see what went wrong:

• Save failed executions. In workflow settings or with EXECUTIONS_DATA_SAVE_ON_ERROR=all on self-hosted n8n.
• Know your retention. By default n8n prunes executions older than 14 days or beyond 10,000 executions, whichever comes first. Investigate failures before they’re pruned, or raise the limits.
• Log dead letters somewhere durable, such as a sheet or table with the item, the error and the time, so nothing depends on execution history alone.

A checklist for each production workflow

1. Retry On Fail on every external call (except unsafe-to-repeat steps)
2. Error workflow set in Settings
3. Every error-output branch ends in an alert or a reviewed log
4. Bad-data checks lead to Stop and Error
5. A heartbeat check for anything business-critical
6. Failed executions saved, and retention known
7. Alerts go to a channel someone reads, and name what to do
8. The workflow is documented: see how to document and hand over automations

The checklist download turns this into an inventory across all your workflows.

Frequently asked questions

Do the same ideas work in Zapier and Make?

Yes. Both have retries or auto-replay, error notifications and error-handling routes. The names differ but the three layers (retry, alert, heartbeat) apply to any automation platform.

How do we avoid alert fatigue?

Retry first, so short blips never reach a person. Send each alert once per failure, with a clear action. Use the heartbeat for “nothing happened” instead of alerting on every quiet hour.

Should failures go to email or chat?

Wherever someone will see them within the time that matters. For leads that’s within the hour, so a team chat or WhatsApp group usually beats an email inbox.

If you’d like your existing workflows reviewed and hardened, that’s part of our tech stack service.