n8n Error Workflows: How to Get Alerted When an Automation Fails

Most automations do not break loudly. A credential expires, an API renames a field, someone adds a question to the website form, and the workflow that used to push leads into your CRM simply stops. Nobody notices until a salesperson asks why there have been no enquiries since Thursday.

n8n records every failed execution, but it tells no one unless you set that up. The tool for the job is an error workflow: a separate workflow that runs whenever another one fails. It is a small build, and it should be one of the first things in place on any n8n instance that handles real business data.

How an error workflow is wired

You build one workflow that starts with the Error Trigger node and save it. Then, in each workflow you care about, open Options > Settings and choose that handler under Error workflow. From then on, when a production execution of the watched workflow fails, n8n runs the handler and passes it the details.

Three points from the n8n documentation that prevent confusion later. The error workflow itself does not need to be published (activated), only saved. One handler can serve every workflow on the instance. And it does not fire on manual runs: clicking “Execute workflow” in the editor and watching a node turn red will not send an alert, which is why many people assume it is broken the first time they try it.

What the Error Trigger receives

For a normal failure, the Error Trigger gets an execution object (id, url, error.message, error.stack, lastNodeExecuted, mode, and retryOf when the run was a retry) and a workflow object (id and name).

There is a catch. If the failure happens in the watched workflow’s trigger node, for example a polling trigger that can no longer authenticate, the execution never properly starts. n8n then sends a trigger object holding the error, and execution carries much less. execution.id and execution.url are also missing when the failed execution was not saved, so make sure the watched workflow’s settings keep failed production executions.

An alert template that assumes every field exists will itself crash in exactly the cases you most need to hear about. Build the message defensively.

A handler that copes with both failure types

Ours has three nodes: Error Trigger, a Code node that formats the message, and whichever channel your team actually reads (Slack, Microsoft Teams, email, or WhatsApp through your messaging provider).

The Code node, left on its default “Run Once for All Items” mode:

const data = $input.first().json;
const wf = data.workflow ?? {};
const exec = data.execution ?? {};
const err = exec.error ?? data.trigger?.error ?? {};

const lines = [
  `n8n failure: ${wf.name ?? 'Unknown workflow'} (ID ${wf.id ?? '?'})`,
  `Failed at: ${exec.lastNodeExecuted ?? 'trigger node'}`,
  `Error: ${err.message ?? 'No message provided'}`,
  exec.url ? `Open execution: ${exec.url}` : 'Execution was not saved',
];

if (exec.retryOf) {
  lines.push(`This run was a retry of execution ${exec.retryOf}`);
}

return [{ json: { text: lines.join('\n') } }];

Set the message field in your Slack or email node to {{ $json.text }}. The execution link is the line that earns its place: whoever picks up the alert can open the failed run and see the exact input that broke it.

Keep the alert path boring. If the handler posts to Slack through the same expired connection that caused the failure, the alert dies too. For workflows that touch revenue, send to two places, such as a team channel plus an email to the person who owns that automation.

The failures n8n never sees

An error workflow runs only when an execution fails. Plenty of real problems finish with a green tick. A node set to On Error: Continue swallows its error and passes empty data downstream. Retry On Fail can keep retrying a flaky API until one attempt gets through, hiding the fact that the integration is getting worse. And an API can return HTTP 200 with an empty result, so the workflow processes nothing and reports success.

For that last case, fail on purpose. The Stop and Error node marks the execution as failed with a message you write, and your error workflow then runs as it would for any other failure.

Take a form-to-CRM workflow, the kind we build as part of CRM implementation. After the node that creates the lead, add an If node that checks the CRM actually returned a record ID:

If node
  Condition: {{ $json.id }}  (String)  is empty
  True branch  -> Stop and Error
                  Message: "CRM create returned no record ID. Check field mapping."
  False branch -> assign owner, send confirmation, continue as normal

Watch what goes into that message. Error text lands in chat channels and execution logs, so point people to the execution instead of pasting a customer’s email or phone number into Slack.

The same pattern fits anywhere “nothing happened” is the problem: a nightly sync that returned zero rows, an invoice run that matched no customers, a webhook payload missing the field your routing depends on.

Testing with a real failure

Since manual runs do not trigger the handler, test with a production execution. Create a throwaway workflow with a Schedule Trigger set to run every minute, followed by a Stop and Error node, and select your handler under Error workflow. Publish it, wait for the alert, check every line reads correctly, then unpublish and delete it.

After that, go through your existing workflows and set the error workflow on each one. It is a per-workflow setting, so add it to the checklist you follow for every new automation.

Start with the workflows that would hurt most if they stopped for a week: lead capture, payment reminders, and anything a client sees. If you want someone to audit your automations and put alerting, ownership and recovery in place, see our workflow automation service or request a quote.