Error Trigger Node
A global error-handling trigger in the n8n workflow platform, used to capture failures in the execution of an entire workflow and to trigger a separate error notification workflow.
Timeline (last 90 days)
The Error Trigger Node is itself an independent workflow trigger: when the monitored workflow fails, n8n triggers this error-handling workflow and passes in error information (such as node name, error message, execution ID).
The Error Trigger's trigger condition is "the entire execution failed", not a single node reporting an error; if a node error is caught and handled by Try Catch, the execution does not terminate in an error state, and the Error Trigger will not fire.
A safer approach is to use both layers: an outer Error Trigger Node to catch all errors not handled locally and push notifications, and an inner Try Catch on known high-risk nodes for in-place retry or degradation handling.
If every node is wrapped in Try Catch, the flow becomes bloated and hard to maintain; if only a global trigger is used, the opportunity for graceful recovery within the flow is lost.
Whether to rethrow an error depends on business semantics: degradable errors (such as cache misses or missing non-critical fields) can be absorbed in place; non-degradable errors (such as authentication failures or loss of core data) should be rethrown to avoid being silently swallowed.
The criterion for choosing between Try Catch and Error Trigger can be simplified to: when this error occurs, can the flow still meaningfully continue? If yes, use Try Catch inline handling; if not, let it fail and hand over to the Error Trigger for alerting and follow-up actions.
Error Trigger and Try Catch are not substitutes but complementary: the global safety net ensures nothing goes unreported, and inline handling ensures recoverability.
All Facts (7)
The Error Trigger Node is itself an independent workflow trigger: when the monitored workflow fails, n8n triggers this error-handling workflow and passes in error information (such as node name, error message, execution ID).
50%UnverifiedThe Error Trigger's trigger condition is "the entire execution failed", not a single node reporting an error; if a node error is caught and handled by Try Catch, the execution does not terminate in an error state, and the Error Trigger will not fire.
50%UnverifiedA safer approach is to use both layers: an outer Error Trigger Node to catch all errors not handled locally and push notifications, and an inner Try Catch on known high-risk nodes for in-place retry or degradation handling.
50%UnverifiedIf every node is wrapped in Try Catch, the flow becomes bloated and hard to maintain; if only a global trigger is used, the opportunity for graceful recovery within the flow is lost.
50%UnverifiedWhether to rethrow an error depends on business semantics: degradable errors (such as cache misses or missing non-critical fields) can be absorbed in place; non-degradable errors (such as authentication failures or loss of core data) should be rethrown to avoid being silently swallowed.
50%UnverifiedThe criterion for choosing between Try Catch and Error Trigger can be simplified to: when this error occurs, can the flow still meaningfully continue? If yes, use Try Catch inline handling; if not, let it fail and hand over to the Error Trigger for alerting and follow-up actions.
50%UnverifiedError Trigger and Try Catch are not substitutes but complementary: the global safety net ensures nothing goes unreported, and inline handling ensures recoverability.
50%