The n8n workflow that runs by itself at two in the morning has one weakness: if it fails, no one sees it. Customer messages are not sent, rows do not enter the spreadsheet, and you only find out three days later. The n8n documentation provides several layers of safeguards for this, each addressing a different question.
First layer: error workflow
An error workflow is a separate workflow that runs when another workflow fails. Here's how it works: the workflow must start with an Error Trigger node, and then the workflow you want to monitor points to it via Options > Settings > Error workflow. One error workflow can serve multiple workflows simultaneously, so just one "guardian" sends notifications to a place you actually read.
The data received by the Error Trigger is sufficient to start an investigation: execution ID and link, error message along with its stack, the last node that was executed, execution mode, as well as the ID and name of the workflow. Fill your notification with the workflow name, the failed node, and its execution link, so that the person receiving it does not have to start from scratch.
Two notes from the documentation that are often overlooked:
- The Error Trigger only activates on failed automatic executions. Running the workflow manually will not trigger it, so the way to test it is by creating a real failure on a scheduled execution or webhook.
- If the failure is due to the trigger itself, the workflow does not get a chance to execute. As a result, the
executionobject (including ID and link) is absent, and the data contains atriggerobject with an error description. Compose your notification message to remain readable even when theexecutionpart is empty.
Second layer: settings in each node
The error workflow captures failures after they occur. Node settings determine what happens when that failure arises. In the Settings tab of a node, there are two things worth checking.
Retry On Fail makes the node try again when it fails. This is suitable for temporary disruptions, such as a busy API. For APIs that limit request rates, the n8n documentation suggests filling in Wait Between Tries (ms) with a value longer than the API's rate limit interval; for example, 1000 ms for an API that allows one request per second. In the HTTP Request node, the Batching options (Items per Batch and Batch Interval) help manage the rate from the start.
On Error has three options:
- Stop Workflow: the entire workflow stops and subsequent nodes do not run.
- Continue: the workflow proceeds to the next node with the last valid data.
- Continue (using error output): the workflow continues, and error information is sent to the next node as a separate branch.
The Continue option is the most risky in workflows that lead to real actions. The last valid data could be sent to the next node, making the workflow appear "successful" even though its content is incorrect. The error output branch is safer because you can decide for yourself: log it, send a warning, or simply skip that item.
Third layer: failing intentionally
Not all issues are considered errors by n8n. Empty data, negative values, or AI responses that do not match the expected format can pass without a single red node. The Stop And Error node forces execution to fail under conditions you specify, with your own text message or JSON object, and the result is captured by the error workflow. Place it in the "illogical" branch after the IF node, and your business rules are monitored.
Logical installation sequence
Start with a single error workflow that sends notifications, connect it to the automatically running workflows, then review the nodes that call external services to determine retry and On Error behavior. Add Stop And Error at critical points, such as before sending messages or writing data. For workflows with AI Agents, this is important because the model's output does not always match the expected format of the subsequent node.