n8n Error Trigger nodeConfigure Error Trigger in n8n.

The most common build is the alert. Behind the Error Trigger, a message lands in the channel where the team already works, through Slack for an ops room or Gmail when the person who needs to know reads email and nothing else. A failed run stops being something you discover three days later in the executions list.

The second build is the log. Instead of a notification you keep a trace, one row per failure in Google Sheets for a small setup, or a table in Postgres once the volume grows. After a few weeks the trace answers a question a single alert never does: which automation breaks often, and which one broke once.

The third build hands the failure to a system that already tracks work. A call through HTTP Request reaches any HTTP endpoint, so an incident tool or an internal API gets the failure without anyone copying it by hand. Keep that node for HTTP APIs: it is the fallback when a dedicated node misses an operation, not a way to speak a protocol that is not HTTP.

When is an error workflow the wrong answer? When the failure is one you can predict and handle inside the workflow that produces it, right where the data still is. The Error Trigger is for what you did not plan for. One more thing decides whether it works at all: the workflow it opens has to be active to listen in production. In the editor a test execution only starts a one off listen, which is enough to check your build and not enough to cover you at night.

The limits are worth knowing before you invest in it. The node has no options, no filter, no version to pick beyond version 1, so every failure that points at this workflow goes through the same path, and any sorting happens in the nodes you place after it. The error workflow can be any workflow on your instance, which means one shared build usually beats one per automation. If you want the wider picture of how triggers, activation and executions fit together, the n8n training covers it end to end.