Error handling, retries and rate limits in n8n

#01Why this matters for marketers

A broken lead routing workflow means leads sit unassigned. A broken report means someone presents old numbers. Most marketing automations fail quietly unless you build alerts. The n8n docs on handling errors gracefully describe the tools; this lesson turns them into a standard setup.

#02The standard setup

Every production workflow should have:

1. An error workflow set in workflow settings.
2. Retries on nodes that call external APIs.
3. Error outputs where some items might fail but others should continue.
4. Validation with IF plus Stop And Error for data that must be present.
5. An owner, named in the workflow description.

#03Item-level versus workflow-level failure

If one lead out of 50 fails enrichment, you usually want the other 49 to continue. That's what Continue (using error output) is for: failed items go down a separate branch, which can log them or alert a person.

If the CRM credential is broken, every item fails, and you want the whole run to stop and alert. That's the default Stop Workflow behaviour plus the error workflow.

#04Don't duplicate side effects

Retries are safe for reads. They're risky for writes: a retried Slack post or email can send twice. For write steps:

• Prefer upserts (such as Sheets Append or Update Row, HubSpot create or update) over plain creates.
• Use Remove Duplicates or a data table "sent" flag before sending.
• Keep retries on the API call, not on whole sections.

#05Silent failures

Error workflows catch errors. They don't catch a schedule that never ran, an API returning empty results, or a filter excluding everything. Add:

• A heartbeat: each run writes a timestamp to a data table; a separate daily workflow alerts if a timestamp is too old.
• Volume checks: alert if results are zero when they shouldn't be.

Our view: the heartbeat check is the most underrated monitor. A report that silently stops is worse than one that fails loudly.

#06Node settings that handle failure

#07What the Error Trigger receives

According to the n8n docs, an error workflow starting with the Error Trigger receives details such as the execution ID and URL, the error message, the workflow name and the last node executed. That's enough for a useful Slack alert with a link straight to the failed execution.

#08Rate limits

The n8n docs on rate limits suggest three approaches: Retry On Fail with a wait between tries; Loop Over Items with a Wait node; and the HTTP Request node's batching option. A 429 error typically shows a message like "The service is receiving too many requests from you".

#09An error alert template

A useful Slack alert includes:

• Workflow name and owner.
• The node that failed and the error message.
• When it happened, in your team's timezone.
• A link to the execution.
• What's affected ("New leads aren't being routed").

#10Error triage guide

Review the errors table monthly. Recurring errors point to design problems, not bad luck.

#11Retry settings in practice

On a node that calls an external API, open Settings and set:

For the HTTP Request node's own batching, set Options, then Batching: items per batch (for example 10) and batch interval (for example 1000 ms). That spaces requests without a separate loop.

#12The error branch, configured

After Continue (using error output), the node has a second output. Connect it to a Google Sheets Append Row with:

• failed_at: {{ $now.toISO() }}
• workflow: {{ $workflow.name }}
• item: {{ JSON.stringify($json) }}
• error: {{ $json.error?.message || 'unknown' }}

Check the actual error field names in a failed test run before mapping, because they vary by node.

#13The heartbeat workflow

1. At the end of each important workflow, a Data table Upsert sets last_success for that workflow's name to {{ $now.toISO() }}.
2. A separate workflow runs daily at 09:00, reads the table, and uses a Filter node to keep rows where last_success is older than expected, such as {{ DateTime.fromISO($json.last_success) < $now.minus({days: 8}) }} for a weekly job.
3. Any rows left trigger a Slack message to the owner.

#14Cost math

The error workflow only runs when something fails. The heartbeat adds about 30 executions a month. Retries happen inside a single execution, so they don't add executions.

#15Ledgerline walkthrough: the first month of alerts

Ledgerline is a fictional accounts-payable software company. Details are illustrative.

In the first month, the error workflow posted six alerts: four were expired Google credentials after a password policy change, one a rate limit on the enrichment API, one a renamed sheet tab. The team added retries with a 3-second wait on the enrichment node and protected sheet tab names.

#16Worked example: Ledgerline's a broken enrichment API

Ledgerline is a fictional accounts-payable software company. Details are illustrative.

Ledgerline's enrichment provider changed its API key format one Friday. The enrichment node failed for every lead.

Because the node used Continue (using error output), leads still reached HubSpot without enrichment and the failure branch filled a "needs manual enrichment" sheet. The error workflow had also posted to #marketing-ops with the execution link. The owner rotated the key on Monday morning and reprocessed the sheet. No leads were lost.

Walkthrough

1. Create a workflow "Marketing error alerts" starting with Error Trigger.
2. Add Slack: post to #marketing-ops: workflow name, last node, error message, and a link to the execution URL.
3. Optionally Data table insert into "errors" for a monthly review.
4. Publish it. In each production workflow's settings, set Error workflow to "Marketing error alerts".
5. In the lead enrichment workflow (lesson 7), set Retry On Fail on the enrichment HTTP Request: 3 tries, 2 seconds apart.
6. Set On Error to Continue (using error output) on the enrichment node, and route failures to a "needs manual enrichment" sheet.
7. Add a Stop And Error node after a check that fails if a required field is empty.
8. Test by breaking a credential on purpose.

#17Try it yourself

Create the error workflow and attach it to two production workflows. Break each one on purpose (wrong credential, bad URL) and confirm the Slack alert arrives with a working execution link. Then fix them.

#18Quick quiz

1. Which node starts an error workflow?

Answer: The Error Trigger.

2. How do you send failed items down a separate path?

Answer: On Error: Continue (using error output).

3. How do you fail a workflow deliberately?

Answer: Use the Stop And Error node.

#19What should you check before the next lesson?

• Every production workflow has an error workflow.
• External API calls retry; sends don't duplicate.
• A heartbeat catches silent failures.

Next: Testing, debugging and AI evaluations. Or return to the n8n for Marketers track.

#20Common questions

Do failed executions count toward my plan? Check the current n8n pricing page; plans count executions, and limits change.

How do I know a schedule didn't run? Error workflows only catch failures. A heartbeat check that alerts when no run is logged catches silence.

Should every node retry? No. Retry calls to external APIs; don't retry steps that send messages twice.