n8n Error Handling: Catch, Notify, and Never Lose a Run

A workflow that fails silently is worse than no workflow at all, because you trust it right up until the day you discover it stopped running last Tuesday. Solid n8n error handling is the difference between "the automation is down" as a Slack alert and "the automation is down" as an angry customer email three weeks later. This guide covers the production pattern: catch every failure, tell a human, and log it so nothing disappears.

Error handling in n8n means building a dedicated error workflow that runs automatically whenever another workflow fails. The Error Trigger node sits at its front, receives details about the failed execution, and hands them to whatever alerting and logging you wire up next. It's the safety net under every automation you actually depend on.

This post is about the catch-notify-log side of resilience. The separate question of re-attempting a flaky step before it counts as a failure is n8n retry logic, and the two work together. Retries stop failures from happening; error workflows catch the ones that still get through.

What n8n error handling should cover

A production-grade error strategy handles more than "send an email when something breaks." The jobs worth automating:

• Detect any workflow failure the moment it happens, without polling
• Alert the right channel (email, Slack, Telegram) with the actual error message
• Log every failure to a durable store so you have an audit trail
• Capture the failed data itself so nothing is silently dropped (the dead-letter pattern)
• Distinguish a one-off blip from a workflow that's failing every run
• Surface the execution URL so you can jump straight to the broken run

Most tutorials stop at the alert. The log and the dead-letter capture are what make the difference at 3 a.m.

The error-handling pipeline

The pattern is a single dedicated workflow that every other workflow points at:

Error Trigger → Set (extract error + execution details)
  → Slack/Email (alert a human)
  → Google Sheets (append to the dead-letter log)

You build this once. Then every workflow in your instance references it in Settings, and you never write per-workflow error code again.

1. Build the error workflow

Create a new workflow with the Error Trigger node (n8n-nodes-base.errorTrigger) as the first node. Per the official n8n error-handling docs, name it something obvious like "Error Handler" and save it. You don't have to activate it; the Error Trigger fires when a linked workflow errors, not on its own schedule.

2. Link it to your real workflows

In each workflow you want protected, open Options then Settings and set the Error Workflow field to the handler you just built, per the n8n docs on error workflows. That's the wire-up. Any automatic failure in that workflow now runs the handler.

One gotcha worth knowing up front: you can't test an error workflow with a manual run. The Error Trigger node docs note it only fires on automatic executions, so you test it by letting a scheduled or webhook-triggered workflow actually fail.

3. Read the error payload

The Error Trigger hands your handler a structured payload. Per the docs, it includes execution.id and execution.url (both require execution data to be saved in the database) and execution.retryOf when the run was itself a retry. It also carries the error message and the name of the node that threw. Pull the fields you need with a Set node or reference them directly, for example the execution URL at ={{ $json.execution.url }}.

4. Alert and log

Now branch the payload two ways. Send the error message and execution URL to a channel a human watches. In parallel, append a row to a Google Sheet or a database table: timestamp, workflow name, node, error message, execution URL. That log is your dead-letter record, the thing that lets you answer "what failed and when" without spelunking through execution history.

Handling errors inside a single workflow

The error workflow catches failures after they crash a run. Sometimes you want to catch a failure mid-flow and keep going. Two node-level tools cover that.

The "On Error" setting

Every node has an On Error option. Left at the default, a failure stops the workflow. Set it to a continue option and the workflow keeps running past the failed item, routing the error down an error output you can handle explicitly. Use this when one bad item shouldn't kill a 500-item batch.

The Stop And Error node

The Stop And Error node (n8n-nodes-base.stopAndError) is the inverse: it deliberately fails a workflow under a condition you define. Per the Stop And Error docs, it's how you enforce a business rule ("if the total is negative, fail loudly") and push a custom error message into your error workflow, rather than letting bad data flow downstream and corrupt something quietly.

The silent-failure trap

Some failures don't throw. A Schedule trigger set to fire every minute will silently drop runs if the previous execution is still in flight, so the workflow "works" but skips executions with no error at all. The fix is a longer cron interval or moving the heavy work to an async pattern. This is the failure mode error workflows can't catch, because nothing errored, and it's why a "did this run when it should have" heartbeat check belongs in any serious monitoring setup.

n8n nodes you'll use most

Getting started

1. Build one error workflow with an Error Trigger as the first node.
2. Add an alert step (Slack, email, or Telegram) with the error message and ={{ $json.execution.url }}.
3. Add a Google Sheets append step so every failure is logged, not just announced.
4. Link the error workflow to your real workflows via Options then Settings then Error Workflow.
5. Set On Error to continue on any node where one bad item shouldn't stop the batch.
6. Add a Stop And Error node wherever a business rule should fail loudly instead of passing bad data through.
7. Let a real automatic run fail once, on purpose, to confirm the whole chain fires.

Error handling is the unglamorous work that decides whether your automation is trustworthy. Catch every failure with an Error Trigger, alert a human, and log the dead-letter record so nothing vanishes. To stop failures before they reach the handler, pair this with n8n retry logic, and to keep bad data out of your workflows in the first place, the Data Gatekeeper — Preflight & Failure Logging template validates every record before it can break anything downstream. For the wider hardening picture, the n8n production setup checklist covers what else to lock down before real traffic.