# Error handling, retries and rate limits in n8n

> Keep marketing automations reliable: n8n error workflows with Slack alerts, Retry On Fail, error outputs, Stop And Error and rate limit patterns.

Source: https://mentionx.ai/learn/n8n/n8n-error-handling-retries  
Author: Dipuck Jones, founder of MentionX  
Updated: 4 November 2026  
Level: Practitioner

**Automations fail: APIs time out, credentials expire, rate limits hit. In n8n you handle this with an error workflow that alerts you, retries on flaky nodes, error outputs for item-level failures, and Stop And Error for checks. Set these up before a workflow goes live.**

> **Key takeaways**
>
> - One shared error workflow posts failures to Slack with a link.
> - Retry On Fail handles temporary API errors.
> - Error outputs route failed items without stopping the run.
> - Watch for silent failures, not just errors.

*Checked 4 November 2026 (CET) against n8n documentation and the n8n pricing page. n8n ships updates often and node options, plan limits and prices change, so confirm in your own instance and on the pricing page. "Our view" marks MentionX opinion. Ledgerline is a fictional company used for illustration.*

## Why 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.

## The 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.

## Item-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.

## Don'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.

## Silent 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.

> **Pro move:** include the workflow owner's Slack handle in the error alert, read from the workflow description or a data table, so the right person sees it.

## Node settings that handle failure

| Setting | What it does | Use for |
|---|---|---|
| Retry On Fail | Retries the node, with Max Tries and Wait Between Tries | Flaky APIs, rate limits |
| On Error: Stop Workflow | Default; the run fails | Steps where failure must stop everything |
| On Error: Continue | Passes on as if successful | Optional enrichment |
| On Error: Continue (using error output) | Sends failed items to a separate output | Routing failures to a log or a person |
| Always Output Data | Outputs an empty item even with no results | Keeping later steps running |

## What 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.

## Rate 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".

## An 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").

## Error triage guide

| Error type | Usual cause | Response |
|---|---|---|
| 401 or 403 | Expired or revoked credential | Reconnect or rotate |
| 404 | Changed URL, deleted record or sheet | Update the reference |
| 429 | Rate limit | Add waits, batching or retries |
| 500 or timeout | Provider problem | Retry; check provider status |
| Validation error | Unexpected input data | Add checks; route bad items aside |

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

## Retry settings in practice

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

| Setting | Suggested value | Why |
|---|---|---|
| Retry On Fail | On | Temporary errors often clear |
| Max Tries | 3 | Enough for brief outages |
| Wait Between Tries (ms) | 2000 to 5000 | Gives rate limits time to reset |
| On Error | Continue (using error output) for item-level work | Failed items go to a separate branch |

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.

## The 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.

## The 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.

## Cost 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.

## Ledgerline 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.

## Worked 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.

## Try 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.

## Quick 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.

## What 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](https://mentionx.ai/learn/n8n/n8n-testing-evaluations). Or return to the [n8n for Marketers track](https://mentionx.ai/learn/n8n/n8n-for-marketers).

## Common 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.

## Sources

- n8n Docs, [Handle errors gracefully](https://docs.n8n.io/build/flow-logic/handle-errors-gracefully)
- n8n Docs, [Handle rate limits](https://docs.n8n.io/integrations/builtin/handle-rate-limits)
- n8n Docs, [Configure workflow settings](https://docs.n8n.io/build/manage-workflows/configure-workflow-settings)
- n8n Docs, [Loop Over Items node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.splitinbatches)
- n8n Docs, [HTTP Request node](https://docs.n8n.io/integrations/builtin/core-nodes/n8n-nodes-base.httprequest)
- n8n Docs, [Slack approvals](https://docs.n8n.io/integrations/builtin/app-nodes/n8n-nodes-base.slack/approvals)
- All accessed 4 Nov 2026.

## Frequently asked 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.

---

Written and reviewed by Dipuck Jones for MentionX Learn. The HTML version of this page: https://mentionx.ai/learn/n8n/n8n-error-handling-retries