How do you monitor n8n automations for errors?
An error workflow can send an alert when an automatic execution fails, while the executions list helps investigate. These are complementary tools in n8n, which we use for automations. They do not by themselves establish that every expected job started and produced the correct business outcome.
How do you configure an error workflow?
Create a workflow starting with Error Trigger and add notification actions, such as email or Slack. Save it. In the monitored workflow, open Options → Settings, select it in Error workflow and save the setting. The documentation allows one handler to serve several workflows.
Adding the node does not automatically configure recipients, access and sending. Check the alert route with a controlled automatic execution. According to the documentation, Error Trigger does not run for manual editor executions; the error workflow itself does not require publishing.
What data does Error Trigger receive?
The data describes the workflow and error: name, identifier, message, stack trace and last executed node as applicable. The execution identifier and URL depend on saving it in the database. A trigger-node failure may omit them and provide more information about the trigger itself.
Do not assume identical fields in every alert. Handle the different cases explicitly. Error data may contain business information; define who receives what rather than forward the full record without review.
How does the executions list help?
Under Overview → Executions, filter by workflow, time and status: Failed, Running, Success or Waiting. Project access and settings affect visibility. This is not a permanent archive of every run: saving and old-data pruning rules apply.
Where the feature and permissions allow, Debug in editor loads failed-run data for investigation. Re-running may repeat an external action. Check what was already recorded or sent and how duplicates will be avoided before another run.
How do alerts and review work together?
An alert identifies a particular failure; periodic review may reveal recurring problems. Compare expected executions with actual ones too. A job that never started is not the same as an execution marked Failed.
A successful technical status does not establish a correct invoice or processing of every expected record. Define the outcome checked under the inventory. n8n provides Stop And Error for a chosen condition, but the condition needs defining; software does not infer the business error.
What happens when a workflow is deleted?
The documentation states that deletion removes its execution history too. Before rebuilding, establish what reference data is needed and whether it remains saved. Exporting the workflow definition does not automatically export the execution history.
Agree necessary retention, access and handling of sensitive data before deletion. A missing record does not establish that a workflow never ran.
Questions
Does every automation need a separate handler?
No. One Error Trigger workflow can be selected for several automations. Configure the applicable data and recipients for each.
What happens without a selected error workflow?
If the workflow contains Error Trigger, the documentation describes it using itself by default. Otherwise, check saving settings and other monitoring channels. Do not assume every error must remain visible or automatically send an email.
Does the list establish the root cause?
It shows available data and may identify the node where failure was detected. That is not always the root cause. Investigate inputs, outside services and completed actions in the particular case.
Sources
Related reading
Next step
Check executions and alert delivery.
Our monitoring checks runs within the agreed inventory, combining alerts with review of records. We define named recipients and check delivery. This does not establish that a person reads an alert immediately; checks for expected-but-missing executions also need defining in scope.
or write to contact@ergostrat.com