Error Handling in n8n: Error Workflows and Error Notifications

An error workflow in n8n is a completely normal automation that you set in the workflow settings under "Error workflow" and that starts automatically as soon as the execution of another workflow fails. Combined with the Error Trigger node, the Retry-On-Fail settings of individual nodes and a notification by email or Microsoft Teams, this ensures that errors do not go unnoticed but are automatically retried or reported to the responsible team. As of: July 2026.

What is an error workflow and when does it trigger?

According to the n8n documentation, an error workflow is a separate workflow that you set "in Workflow Settings" for another automation and that is executed as soon as its execution fails. According to the documentation, a typical use case is to send "email or Slack notifications" in the event of an error. A single error workflow can be reused for multiple production workflows, so you do not have to build separate error handling for every automation. It is important to note that an error workflow cannot be tested by running it manually: according to the documentation, the Error Trigger only reacts when an automated execution of another workflow actually fails. Further details can be found in the n8n documentation on error handling.

How do you set up an error workflow?

You first create a standalone workflow that exists exclusively for the error case, and then link it to the workflow to be monitored.

• Create the error handler workflow: Create a new workflow with the Error Trigger as the first node, give it a name such as "Error Handler" and save it.
• Open the target workflow: Open the workflow whose errors you want to monitor, and go there to Options and then Settings.
• Assign the error workflow: In the "Error workflow" field, select the previously created error handler workflow and save the setting.

A workflow that is only started via the Error Trigger does not need to be published separately for it to function as an error workflow.

What information does the Error Trigger provide in the event of an error?

The Error Trigger passes structured data about the failed execution, from which a meaningful notification can be composed. According to the documentation on the Error Trigger node this data includes, among other things:

• execution.id and execution.url: identifier and link to the failed execution, but missing if the error already occurs in the triggering trigger node of the main automation.
• execution.error: the actual error message including stack trace.
• execution.lastNodeExecuted: the node at which the execution failed.
• execution.retryOf: only present if the failed execution was itself already a retry.
• workflow.id and workflow.name: which workflow is affected.

In addition, the Stop And Error node can be used to deliberately force an error, for example to intentionally trigger the error workflow in the case of implausible data, even if there is technically no node error.

How can a failed call be automatically retried?

Before an execution is even considered to have finally failed and ends up in the error workflow, each individual node can be configured to automatically retry a failed call several times first. To do this, open the relevant node, switch to the settings and enable "Retry On Fail" there. Use "Max Tries" to specify how many times n8n repeats the attempt, and "Wait Between Tries (ms)" to set the wait time between attempts in milliseconds. Both values are limited according to the documentation on handling API rate limits: Max Tries to a maximum of 5, Wait Between Tries to a maximum of 5000 milliseconds. Especially for services with rate limits, the documentation recommends setting the wait time above the rate limit interval of the respective API so that the next attempt is not rejected again.

How do you notify your team by email or Microsoft Teams?

After the Error Trigger, simply add the node in the error workflow through which the notification should be sent. For email notifications, the Send Email node is suitable, which requires an SMTP credentials connection and sends messages as text, HTML or both formats. For reporting in a Teams channel, the Microsoft Teams node is available, which posts messages to a channel using stored Microsoft credentials. In both cases, you build the message text from the fields provided by the Error Trigger, such as the workflow name, the error message from execution.error and the link to the execution via execution.url, so that recipients can immediately see which process is affected and where they can find the details. Anyone who wants an existing n8n environment secured with technical expertise using error workflows, retry strategies and notifications can find support from the n8n services from NordFlux.

Frequently asked questions about error handling in n8n

Do I need a separate error workflow for every workflow?

No, a single error workflow can be set as a shared error workflow in the settings of multiple workflows. This means a central notification automation is often enough for many production workflows. For particularly critical processes, you can still create a specialized error workflow with its own escalation logic.

Can I test an error workflow manually?

No, according to the n8n documentation, an error workflow cannot be tested by running it manually, because the Error Trigger only reacts when an automated execution of another workflow actually fails. To test the behavior anyway, you can use the Stop And Error node in a test workflow to deliberately force an error and thus trigger the linked error workflow.

What is the difference between Retry On Fail and an error workflow?

Retry On Fail automatically repeats the call of a single node within the same execution, while the error workflow only takes effect once the entire execution has finally failed despite all retry attempts. Both mechanisms complement each other well: retries absorb short term disruptions such as exceeded rate limits, while the error workflow subsequently informs people about final failures.

Does the error handler workflow need to be activated or published?

No, a workflow that is started exclusively via the Error Trigger does not, according to the documentation, need to be published separately in order to work. It is called automatically as soon as another workflow references it in its settings as an error workflow and itself fails.