n8n Error Workflow: Catch Every Failure in Production

6 min read · Last updated: October 25, 2026

An n8n error workflow is a separate workflow that starts with the Error Trigger node and runs whenever a linked workflow fails in an automatic run. Set it once in each workflow's settings, send an alert from it, and write every failure to a data table so repeat offenders show up within a week.

Came here from Instagram, LinkedIn, X or YouTube? Here is the full source list you came for. Everything below is built from these, nothing else.

The docs (all accessed October 25, 2026)

• n8n docs: Error handling
• n8n docs: Error Trigger node
• n8n docs: Nodes (Retry On Fail and On Error settings)
• n8n docs: Data tables
• n8n docs: Data Table node

Key takeaways

• One error workflow can serve many workflows, so you build the handler once.
• The error workflow must start with the Error Trigger node.
• Error workflows do not run on manual executions, so you test with a deliberate failure on an automatic run.
• A failing trigger node sends a different payload, with details in trigger{} instead of execution{}.
• n8n data tables are capped at 200 MiB by default, which is plenty for a text-only failure log.
• A node set to Continue on error hides failures from your error workflow's alert unless you handle that output yourself.

What will you build, and why?

You will build one n8n workflow that every other workflow reports to. It does three jobs: it catches a failure, it sends you an alert with the workflow name, the failed node and a link to the execution, and it appends a row to a failure log.

The alert tells you something broke today. The log tells you what keeps breaking. After a week of rows, the same workflow or node appears again and again, and that is where you fix things first.

The whole build is one handler, one alert and one table. No extra service is needed.

What do you need before you start?

You need an n8n instance where you can create workflows, at least one production workflow to protect, and a place to send alerts. The n8n docs give email or Slack as examples of what an error workflow can send.

• An n8n instance with the Data tables feature (the Data tables tab in your project).
• One production workflow that runs on a schedule or a webhook, not only manually.
• A Slack channel or an email address that you actually read.

How do you build an n8n error workflow, step by step?

Create a workflow that starts with the Error Trigger node, add an alert and a log step, then select it under Error workflow in every production workflow's settings. The docs say the error workflow must start with the Error Trigger, and one error workflow can serve several workflows.

1. Create the handler workflow. Name it something obvious like Global error handler. Add an Error Trigger node as the first node. According to the n8n docs, you do not need to publish a workflow that contains the Error Trigger.
2. Create the failure log. In your project, open the Data tables tab, click the split button in the top right and choose Create Data table. Name it failure_log. Choose From scratch and add these columns:

Column	What it holds	Source field in the payload
workflow_id	ID of the failed workflow	workflow.id
workflow_name	Name of the failed workflow	workflow.name
node	The node that failed	execution.lastNodeExecuted
message	The error message	execution.error.message
mode	How the run started	execution.mode
execution_url	Link to the failed run	execution.url
is_trigger_failure	True if the trigger node failed	trigger object present

3. Normalise the payload. The Error Trigger sends one shape for normal failures and another when the main workflow's trigger node fails. Add a Code node after the trigger that turns both into one flat row:

const e = $input.first().json;
const isTrigger = Boolean(e.trigger);
const err = isTrigger ? e.trigger.error : e.execution.error;
const failedNode = isTrigger
  ? (typeof err?.node === 'object' ? err.node?.name : err?.node)
  : e.execution.lastNodeExecuted;

return [{
  json: {
    workflow_id: String(e.workflow?.id ?? ''),
    workflow_name: e.workflow?.name ?? 'unknown',
    node: failedNode ?? 'unknown',
    message: err?.message ?? 'no message',
    mode: (isTrigger ? e.trigger.mode : e.execution.mode) ?? '',
    execution_url: e.execution?.url ?? '',
    is_trigger_failure: isTrigger,
  },
}];

4. Write the row. Add a Data Table node, set the operation to Insert, pick failure_log and map each column to the matching field from the Code node. The docs describe Insert as "Insert rows into an existing table."
5. Send the alert. Add a Slack or email node after the Data Table node. Put the facts you need in the first line so you can read it on a phone lock screen:

FAILED: {{ $json.workflow_name }}
Node: {{ $json.node }}
Error: {{ $json.message }}
Run: {{ $json.execution_url }}

Wire the alert in parallel with the Data Table node, not after it. That way a full table cannot stop the alert from firing. 6. Attach the handler to your workflows. Open each production workflow, go to Options > Settings and select Global error handler under Error workflow. Do this for every workflow, including new ones. This is the step people forget.

How do you test that it really works?

You test it by making a real workflow fail on an automatic run. The n8n docs state: "You can't test error workflows when running workflows manually." Running the handler by hand will not prove that the setting is connected.

Use the Stop and Error node. The docs say it forces an execution to fail under chosen conditions, and that it also triggers the error workflow.

1. Add a Stop and Error node at the end of a test workflow with a message like error workflow test.
2. Give the test workflow a Schedule trigger that fires every minute, and select the global handler under Error workflow in its settings.
3. Wait for the next run and check three things: the alert arrived, the row is in failure_log, and execution_url opens the failed run.
4. Switch the schedule off.

Note that execution.id and execution.url need the execution to be saved in the database. If the failure happens inside the main workflow's trigger node, the workflow never executes, so those two fields are missing. That is why the Code node above falls back to empty strings.

How does the failure log show patterns within a week?

Count rows by workflow and node. A workflow or node that appears several times in seven days has a real problem, while a single row is usually noise. Group the log once a week and send yourself the top offenders.

Create a second workflow with a Schedule trigger (weekly), a Data Table node with the Get operation on failure_log, and this Code node:

const counts = {};
for (const item of $input.all()) {
  const key = `${item.json.workflow_name} > ${item.json.node}`;
  counts[key] = (counts[key] ?? 0) + 1;
}

const top = Object.entries(counts)
  .sort((a, b) => b[1] - a[1])
  .slice(0, 5)
  .map(([key, n]) => `${n}x  ${key}`)
  .join('\n');

return [{ json: { digest: top || 'No failures this week' } }];

Send digest to the same channel as your alerts. Two things you should look for in the output:

Pattern in the log	What it usually means	What to do
Same node, many rows	A flaky external API or a bad credential	Turn on Retry On Fail for that node
Many workflows, same message	A shared dependency is down	Fix the dependency once
is_trigger_failure is true	The trigger itself is failing	Check the trigger credentials and settings
One workflow, one row, once	Likely a one-off	Leave it

The docs describe Retry On Fail as: "When an execution fails, the node reruns until it succeeds." Use it on the node the log blames, not on every node by default.

What are the common mistakes with n8n error workflows?

The most common mistakes are forgetting to attach the handler, hiding failures with Continue, testing by hand, and letting the log grow without a plan. Each one makes the setup look fine while failures slip through silently.

Mistake	Why it hurts	Fix
New workflow never linked to the handler	Its failures send nothing	Add the Error workflow setting to your new-workflow checklist
On Error set to Continue	The node passes on despite the error, so the workflow succeeds and nothing alerts	Use Continue (using error output) and route that output to the handler yourself, or use Stop Workflow
Testing with a manual run	Error workflows do not run on manual executions	Use a scheduled test with Stop and Error
Assuming execution.url always exists	It is missing when the trigger node fails	Read the trigger object as a fallback
Alert placed after the log insert	If the insert fails, no alert fires	Run both branches in parallel
Storing full payloads in the log	Data tables share a default 200 MiB instance limit	Log the message and IDs, not the data

The last row matters more than it looks. According to the n8n data tables docs, n8n warns you as tables approach 80% of the limit. Once you exceed it, manual additions are disabled and workflow executions that insert or update data fail. A bloated log can break the very workflows it watches. Self-hosted instances can raise the limit with the N8N_DATA_TABLES_MAX_SIZE_BYTES environment variable.

One more behaviour to know: by default, a workflow containing the Error Trigger uses itself as its error workflow. Keep the handler small so there is little in it that can fail.

What should you do next?

• Add a retry rule. Turn on Retry On Fail for the one node your weekly digest blames most.
• Fail on purpose for bad data. Use Stop and Error with a clear message when an input is wrong, so the log reads like a sentence.
• Review the log every Monday. Five minutes with the digest beats an hour of hunting through execution history.
• Prune old rows. The Data Table node supports a Delete operation for rows you no longer need.
• Review what AI writes for you. If an AI assistant drafts your workflow code, check it before it runs in production. Our guide on how to review AI-generated code like a pro covers what to look for.

If you are deciding how your own services should report errors, why your private API doesn't need HTTP status codes is a useful companion read. And if you are new to building with AI help, start with build an app with Claude Code as a beginner.

FAQ

What is the Error Trigger node in n8n?

The Error Trigger node starts an error workflow. When a linked workflow fails, it receives details about the failed run, including the workflow ID and name, the execution ID and URL, the error message and stack, and the last node executed.

Can one error workflow handle all my n8n workflows?

Yes. According to the n8n docs, one error workflow can serve several workflows. You select it under Options > Settings > Error workflow in each workflow you want to monitor. The setting is per workflow, so you still have to attach it to each one.

Why did my n8n error workflow not run?

The usual causes are a manual test run, a missing Error workflow setting, or a node set to Continue on error. The docs say error workflows only run on automatic errors, so test with a scheduled run and a Stop and Error node.

What happens when the trigger node itself fails?

The Error Trigger sends a different payload. Details move from execution{} into trigger{}, which holds the error and the mode. Because the workflow never executes, execution.id and execution.url are missing, so your handler should read the trigger object as a fallback.

Start with the handler today, then browse the free tools on Art of Code and the other guides on the blog.

Written by Adithya Guttha, Founder of Art of Code.