---
title: "Error Handling in N8N: Retries, Alerts and Error Workflows"
description: "Learn how to handle failures in N8N with retries, error outputs, the Error Trigger node and alerts, so no automation stops silently."
url: https://lui.cx/en/blog/n8n-error-handling
source: https://lui.cx/en/blog/n8n-error-handling
generated_by: aeo.js
---

# Error Handling in N8N: Retries, Alerts and Error Workflows

Learn how to handle failures in N8N with retries, error outputs, the Error Trigger node and alerts, so no automation stops silently.

GUIDEn8nerrorsmonitoringbest practices

## Error Handling in N8N: Retries, Alerts and Error Workflows

Learn how to handle failures in N8N with retries, error outputs, the Error Trigger node and alerts, so no automation stops silently.

By lui.cx Team · October 22, 2026

Every automation will fail someday. An API goes down, a credential expires, a customer fills in a field in an unexpected way. The problem isn't the failure itself, but finding out days later that an important process stopped without telling anyone. In this article, we'll look at the tools N8N offers for handling errors and how to combine them into a simple strategy.

## Why handle errors from the start

A workflow without error handling works fine while everything goes right. When something fails, the execution stops at the failing node and the rest of the workflow doesn't run. If nobody checks the executions list, the failure goes unnoticed.

Handling errors from the start brings three benefits:

-   Temporary failures resolve themselves, with no intervention.
-   Permanent failures reach whoever can fix them, as soon as they happen.
-   Data that couldn't be processed is recorded for another attempt.

## Most common error types

| Type | Example | Best response |
| --- | --- | --- |
| Temporary | Timeout, rate limit, instability | Try again after a few seconds |
| Data | Empty field, invalid format, missing record | Route the item aside and record the reason |
| Configuration | Expired credential, permission denied | Alert the team immediately |

Separating errors by type helps you choose the right tool for each one.

## Automatic retries

Each node's settings include the Retry On Fail option. When you turn it on, you set how many attempts N8N should make and how long to wait between them.

It's ideal for HTTP requests and integrations with external services, where most failures are transient. A common setup is three attempts a few seconds apart. For APIs with rate limits, increase the interval so the limit has time to reset.

Retries don't fix data or configuration errors. Repeating a call with an expired credential only delays the alert.

## Continuing the workflow when a node fails

Also in the node settings, the On Error option defines what happens when retries run out:

1.  Stop the workflow: the default behavior. The execution ends with an error.
2.  Continue: the workflow proceeds with whatever data the node managed to produce, ignoring the failure.
3.  Continue using the error output: the node gets a second output, through which only the failed items pass.

The third option is the most useful for data errors. Valid items follow the normal path, while problematic ones go to a separate branch, where they can be saved to a pending spreadsheet or sent for review.

## The error workflow

For failures that stop the execution, N8N lets you define an error workflow. It's a separate workflow that starts with the Error Trigger node and runs automatically whenever another workflow fails.

To set it up:

1.  Create a new workflow with the Error Trigger node as the trigger.
2.  Add the nodes that should notify the team, such as email, Slack, Telegram or WhatsApp.
3.  In the settings of the workflow you want to protect, select that workflow in the error workflow field.

The Error Trigger receives the name of the failed workflow, the node where the error happened, the error message and the link to the execution. That way, the alert arrives with everything needed to investigate.

A single error workflow can serve all your workflows. That keeps alerts consistent and everything in one place.

## Raising errors on purpose

Sometimes the workflow doesn't fail technically, but the result is wrong. A query that should return a customer comes back empty, or a value arrives negative.

For these cases, use the Stop and Error node. It stops the execution with a message you define and triggers the error workflow like any other failure. It's how you turn a business rule into an alert.

## Best practices for alerts

-   Send alerts to a channel the team actually follows.
-   Include the execution link, the workflow name and the error message.
-   Avoid alerts for failures already handled by retries.
-   Group repeated failures so you don't get dozens of identical messages.
-   Review failed executions every week, even when nothing seemed urgent.

## A simple strategy to get started

If you don't handle errors yet, start with these three steps:

1.  Turn on retries for every node that calls external services.
2.  Create an error workflow with an alert to the team channel and link it to your most important workflows.
3.  Use the error output on nodes that process data coming from people, such as forms and spreadsheets.

These steps take less than an hour and eliminate most silent failures.

## Infrastructure matters too

Error handling covers what happens inside your workflows. But if the N8N instance goes down, no error workflow will run.

With lui, each customer has a dedicated N8N instance, isolated from the others and looked after by our team. You take care of your workflow rules and lui takes care of the infrastructure that keeps them running.

## Conclusion

Reliable automations aren't the ones that never fail, but the ones that fail visibly and recover on their own when possible. By combining retries, error outputs, an error workflow and well-designed alerts, you make sure no important process stops silently.

[Explore all articles](/en/blog)