Introduction

In any production workflow, things will go wrong. An API returns a 500, a webhook payload is malformed, a database connection times out. The question is not whether failures happen — it is whether your workflow handles them gracefully or silently drops the ball.

n8n gives you two layers of error handling: local error handling at the node level, and a dedicated Error Trigger node that lets you build a separate workflow specifically for catching and responding to failures. This lesson covers both, with a focus on getting real alerts into your hands when something breaks.

How n8n Handles Node Failures by Default

By default, when a node throws an error, n8n stops execution for that path and marks the execution as failed. You will see the error in the execution history, but nothing proactive happens — no alert, no retry, no fallback.

For each node, you can change this behavior in the node's settings panel. The three most useful options are:

Stop workflow on error — the default behavior. Execution halts at the failed node.

Continue on error — n8n passes execution forward even if the node fails. The output item from the failed node will carry error information in a special field, which you can inspect downstream.

Retry on fail — n8n automatically retries the node a configurable number of times with a delay between attempts. This is useful for transient failures like rate-limit responses or flaky network calls.

To configure these, open any node, go to Settings, and look for the "On Error" section. For retry, you also set "Retry On Fail" to true and define "Max Tries" and "Wait Between Tries" in milliseconds.

Continue on error is particularly powerful when you want to process a batch of items and not let one bad record kill the entire run. The downstream node receives an item that looks like this:

{
  "error": {
    "message": "Request failed with status code 404",
    "node": "HTTP Request",
    "stack": "..."
  }
}

You can then use an IF node to check whether the item has an error field and route it to a separate branch for logging or alerting.

Configuring an Error Workflow with the Error Trigger

Node-level settings handle individual node failures, but what about catching any failure across an entire workflow? That is what the Error Trigger node is for.

The Error Trigger works at the workflow level. You create a separate workflow — call it something like "Global Error Handler" — and set its trigger to Error Trigger. Then, in any other workflow, you go to Settings and set the "Error Workflow" field to point to this handler workflow.

When the parent workflow fails, n8n automatically starts the error handler workflow and passes it a payload with details about what went wrong. The payload structure looks like this:

{
  "execution": {
    "id": "1042",
    "url": "https://your-n8n.com/execution/1042",
    "retryOf": null,
    "error": {
      "message": "Could not connect to the database",
      "stack": "Error: Could not connect..."
    },
    "lastNodeExecuted": "Postgres",
    "mode": "trigger"
  },
  "workflow": {
    "id": "88",
    "name": "Daily Invoice Sync"
  }
}

This gives you everything you need: which workflow failed, which node was last to execute, the error message, and a direct link to the execution log.

To set up the Error Trigger workflow:

1. Create a new workflow and add the Error Trigger node as the start node. 2. Add whatever alert step you need — Slack, email, PagerDuty, or an HTTP Request to a webhook. 3. Save and publish the workflow. 4. In your production workflows, open Settings and set "Error Workflow" to this handler.

You can set one global error handler and reuse it across every workflow in your instance.

Sending Alerts When Something Goes Wrong

The most common thing to do in an error workflow is send a notification. Here is an example that posts a message to a Slack channel using the data from the Error Trigger:

// Inside a Slack node's message field (using an expression)
`Workflow "{{ $json.workflow.name }}" failed.
Node: {{ $json.execution.lastNodeExecuted }}
Error: {{ $json.execution.error.message }}
View execution: {{ $json.execution.url }}`

If you prefer to use the HTTP Request node to call a Slack webhook directly:

{
  "text": "=Workflow \"{{ $json.workflow.name }}\" failed at node {{ $json.execution.lastNodeExecuted }}: {{ $json.execution.error.message }}"
}

For email alerts via the Send Email node, map the error fields into the subject and body the same way. The key is that every field in the Error Trigger payload is accessible through the normal expression syntax.

You can also add a Set node before your alert step to reshape or enrich the data — for example, appending a severity level based on the workflow name, or adding a timestamp.

Common Mistakes

Pointing Error Workflow at itself — if your error handler workflow also errors, n8n will not recursively trigger it again, but you will lose visibility. Keep error handler workflows simple and dependency-light.

Forgetting to publish the error handler — a workflow set as the Error Workflow must be active. If it is saved as a draft, it will not execute.

Using Continue on Error everywhere — this can hide real failures. Reserve it for cases where you have explicit downstream logic to handle the error item. Do not use it as a way to silence errors you do not want to deal with.

Not testing the error path — create a test workflow with a deliberate failure (an HTTP Request node pointing to a URL that returns 500) and verify that your error handler actually fires and sends the alert you expect.

Summary

Node-level settings let you control behavior on individual failures: stop, continue, or retry. The Error Trigger node lets you build a centralized handler that fires whenever any linked workflow fails, giving you the execution context you need to send a meaningful alert. Together, these two layers cover the vast majority of production error handling needs in n8n without requiring any custom code.