n8n error handling in production: get alerted when a workflow fails, and know what to do next

Why an n8n workflow fails in production

A workflow depends on services and data that change without notice. The usual causes:

• Credentials. A token expires, a password changes, or the employee who connected their account leaves the company.
• APIs. A vendor renames a field, retires an old version or limits the number of requests.
• Data. An invoice in an unknown format, or a required field left empty.
• The trigger. The starting node fails and the workflow never runs.
• Resources. The n8n documentation lists node configuration errors and running out of memory among the common reasons for failure.

n8n misses two cases. In the first, an AI step returns a well-formed but wrong answer, for example a misread amount, and the execution is marked as successful. In the second, the workflow no longer runs at all, because someone deactivated it while editing it. No execution means no error. So you need to handle three situations: technical errors, business anomalies and silence.

n8n error handling: the error workflow and the Error Trigger node

The core mechanism is the error workflow. It is an ordinary workflow that starts with the Error Trigger node, and n8n runs it when an execution of another workflow fails. To set it up:

1. Create a workflow that starts with the Error Trigger node, give it a name such as "Error handling", and save it.
2. Add the nodes that send the alert after it.
3. In each workflow you want to monitor, open Options > Settings, select this workflow in the Error workflow field, and save.

One error workflow can serve several workflows. To start with, I recommend a single error workflow for the whole company, so you have one alert format and one place to maintain. The setting still has to be made workflow by workflow, though, and a workflow you forget to configure will alert no one.

According to the documentation, the error workflow does not need to be published. It only reacts to failed automatic executions, not to tests you run by hand in the editor. To test it, create a small dedicated workflow with no side effects: it reads and writes no real data and simply fails on purpose with a Stop and Error node. Schedule it at a low frequency, for example once a day, and deactivate it as soon as the alert arrives. A failing test workflow left running would end up flooding your alert channels.

The error workflow uses credentials of its own, for Slack or for your email. If they expire, every alert stops at once. Send alerts through two independent channels, for example your team chat and email.

What the alert should contain

A useful alert tells the person who receives it what is broken and whether it is urgent, without opening n8n. The Error Trigger receives specific data:

In a sending node, you use these fields through expressions, for example {{ $json.workflow.name }} or {{ $json.execution.url }}.

Add two pieces of information that n8n does not have: the name of the workflow's owner and a link to its recovery procedure. A lookup table keyed by workflow name is enough.

Trigger errors. When the failure comes from the starting node, the workflow does not run. The Error Trigger then receives no execution ID and no execution link: the execution block carries less information, and the details arrive in a trigger block instead (error name, for example WorkflowActivationError, message, timestamp and the node involved). A message built around execution.url will arrive incomplete. Put an If node first that checks the execution ID safely, with the expression {{ $json.execution?.id }}: the ?. prevents an error if the execution block is missing. You can also check whether the trigger block exists. Prepare two message formats and test both paths, for example with the two sample payloads published in the documentation.

The execution ID and link also assume that the execution is saved to the database. Check that your instance keeps failed executions.

Finally, error messages can contain customer data. Send alerts to a private channel.

Making a workflow fail on purpose with Stop and Error

The error workflow only sees failed executions. For an invoice with no amount or an inconsistent AI answer, you have to trigger the failure yourself. That is the job of the Stop and Error node. It fails the execution under conditions you choose and passes a custom message to the error workflow. It offers two error types: Error Message, a plain text, and Error Object, a JSON object with whatever properties you want.

An If node checks a business condition, and the "anomaly" branch leads to the Stop and Error node. A few useful checks:

• Missing or zero amount after extracting an invoice.
• Unknown supplier: not in your supplier list.
• Unreadable AI answer: the expected JSON cannot be parsed, or the category returned is not in the expected list.
• Inconsistency: the total including VAT does not equal the net amount plus VAT.

Write the message for the person who will read it. "Invoice with no amount, supplier Dupont, file invoice-0412.pdf" takes two minutes to handle. "Validation failed" requires an investigation.

One caveat: a failure stops the whole execution, so one abnormal invoice can block the nineteen others in the same batch. For batch processing, I prefer sending the suspicious item to a "to review" queue with a notification and letting the rest through. Stop and Error fits cases where the remaining steps make no sense without the missing data. Checks specific to AI steps are covered in the article on human approval for AI agents in production.

Where to send the alert and who handles it

The documentation uses email and Slack alerts as examples. Teams works too if that is what your team uses. The right channel is one that someone actually reads, not a feed buried under notifications.

For each critical workflow, name one specific person as owner, plus a backup for holidays. "The team" does not handle alerts.

Then write a half-page recovery procedure for each critical workflow:

• what the workflow does, and what a one-day outage costs
• what to check first (credentials, a third-party service outage, the file received)
• who to contact: the bank, the supplier, the accountant, the person who built the workflow
• how to rerun without creating duplicates
• what to do by hand while the workflow is down

For a Qonto bank reconciliation with n8n, a one-day outage can wait until the next day. For email triage that flags complaints, the response time has to be shorter. Write that response time into the procedure.

Investigating and rerunning without duplicates

The link in the alert opens the failed execution. You can also browse the execution history for a single workflow, or for all the workflows you have access to.

To reproduce the problem, n8n lets you load data from a past execution into the workflow you are editing. You fix the faulty node and test it with the invoice or email that caused the error. If you want to centralize logs in an external tool, the documentation also mentions log streaming. Check whether your plan includes it.

Before rerunning, look at what the execution already did. The steps before the failure have happened: an invoice already created, an email already sent. Rerunning everything duplicates them.

Three habits limit that risk:

• A unique key per item (invoice number plus supplier, transaction ID). Before creating anything, the workflow checks that the item does not already exist in the destination tool.
• A marker at the end of processing (a label, a status, a row in a tracking table) that the trigger excludes.
• Irreversible actions last, after every check, with each send logged.

When these safeguards are missing, finishing the few affected items by hand is safer than rerunning blindly.

Weekly routine and checklist for a company of 5 to 50 people

I recommend a fifteen-minute review each week, covering four points.

Critical workflows. The ones that touch money, customers or legal obligations. Go through their failures for the week, including the ones already handled.

Silent workflows. The error workflow cannot detect a workflow that has stopped running. A simple fix: in its last step, each critical workflow writes the date of its last successful run to a table. A scheduled workflow checks every morning that these dates are recent, and sends an alert if not.

Expiring credentials. Put known deadlines in a calendar: bank connections, API keys with a limited lifetime, employees leaving.

Updates on self-hosted instances. Read the release notes, back up, then test your critical workflows after updating. If your server goes down, the error workflow goes down with it, so you need external monitoring of the instance. These topics are covered in the article on the Hetzner, Coolify and n8n stack.

The checklist, to apply to your existing workflows:

• Every production workflow has an error workflow set in its settings.
• The error workflow handles trigger errors, which have no execution ID, and both of its paths have been tested.
• The alert includes the workflow name, the last step, the message, the link and the owner's name.
• The alert goes out through two channels, in a private space.
• Critical business anomalies are turned into errors or "to review" items.
• Every critical workflow has an owner, a backup and a written recovery procedure.
• Workflows that create invoices or send emails check whether an item exists before creating it.
• A daily check flags critical workflows that have not run.
• Credential expiry dates are in a calendar.
• The alert is tested once a month with a test workflow that has no side effects and is deactivated after the test.

What you can do yourself, and when to get help

Someone comfortable with n8n can set up the error workflow, the alerts and the routine on their own. Naming owners and approving procedures is a decision for management.

An outside view becomes useful when dozens of workflows have piled up without documentation, when financial flows need to be rerunnable without duplicates, or when a self-hosted instance has no monitoring at all. The criteria for deciding between doing it yourself and getting help are covered in what you can automate yourself with n8n. At Kirako, we handle these topics in our n8n automation projects.

A workflow with no alerting will eventually fail without anyone noticing. With an error workflow, a few business checks, a named owner and fifteen minutes of review a week, a failure can be spotted the same day instead of turning up in the month-end accounts.

Sources

Consulted on 6 November 2026: n8n documentation (error handling and error workflow, Error Trigger node, Stop and Error node).