The Error Trigger node is the foundation of n8n’s global error
handling system. When any production workflow fails, this node automatically
receives a structured JSON payload containing the failed workflow’s ID, name,
execution URL, error message, stack trace, and last node executed. Unlike manual
triggers, it cannot be tested by clicking “Execute Workflow” — it fires only
when an automated execution fails. This guide covers the complete setup: creating
error workflows, parsing error data, building retry loops with exponential
backoff, and sending multi‑channel alerts.

How do you create an error workflow and set up the Error Trigger node in n8n?

Create a new workflow, name it “Error Handler” or “ERROR NOTIFIER”, and add the
Error Trigger node as the first node. This node requires no
configuration—it automatically receives error data from any failing workflow.
Then, in each production workflow’s Settings panel, select this error handler
from the Error Workflow dropdown. One error workflow can monitor
multiple production workflows.

The Error Trigger node is part of n8n’s built-in core nodes and requires no
activation—n8n’s engine manages it internally. When any monitored workflow
fails, n8n sends a JSON payload containing execution.id,
execution.url, error.message, error.stack,
lastNodeExecuted, and workflow.name. If the failure
originates in the main workflow’s trigger node, n8n delivers a separate
trigger object with a WorkflowActivationError event instead.
A critical limitation: the Error Trigger only fires on automatic executions—
you cannot test it by clicking “Execute Workflow” manually.
For the complete production error handling architecture covering three layers
(node-level retries, global error trigger, centralized logging), see the
n8n nodes by use case guide.

How do you parse and classify error data from the Error Trigger for intelligent routing?

Place a Set or Code node after the Error
Trigger to extract and classify error data. Use
{{ $json.error.message }} to pull the error
message and {{ $json.workflow.name }} for the
workflow name. A Code node can classify errors into categories—Auth Error,
Rate Limit, Network, Data/Config Error, Not Found, Server Error, Permission—
by pattern‑matching on error messages or status codes.

For instance, if the error message contains “401” or “403”, classify as Auth Error;
“429” maps to Rate Limit; “ECONNREFUSED” or “ETIMEDOUT” maps to Network. Once
classified, a Switch node routes each category to a different handler: Auth
errors go to a credential refresh workflow, Rate Limit errors enter a retry
queue, and Network errors trigger a delayed re‑execution. This triage pattern
is how teams running 200+ production workflows achieve a 99.4% error detection
rate with mean time to detect under 90 seconds.
For more on classification patterns, see the
IF & Switch node branching guide.

How do you configure retry logic with exponential backoff and jitter for transient failures?

n8n provides two levels of retry: node‑level Retry on Fail
(enable in any node’s Settings panel, set max retries to 2–3, and configure
wait time between attempts) and workflow‑level retry loops
built with Code, Wait, and IF nodes. For transient failures like API timeouts
and rate limits, node-level retry is sufficient; for complex patterns, use a
loop with exponential backoff.

The production‑grade retry template classifies failures into retryable status
codes (408, 409, 425, 429, 500, 502, 503, 504) and non‑retryable (400, 401,
403, 404, 422), then applies the formula:
waitSeconds = min(maxDelay, baseDelay × 2^(attempt−1))
with ±25% random jitter to prevent thundering‑herd retry storms. After all
retries are exhausted, the workflow sends Slack and email alerts and optionally
calls Stop And Error so a global Error Workflow captures the final failure.
For the complete importable template with pre‑configured retry logic, see the
SplitInBatches loop and iteration guide.

How do you send Slack, email, and multi-channel alerts from an error workflow?

After the Error Trigger and a Set node that formats the error data, add a
Slack node to send a formatted message to a dedicated
#n8n-errors channel. The message should include the workflow
name, failed node, error message, timestamp, and a clickable execution URL.
For email, use the Gmail or SMTP node with
an HTML‑formatted body containing the same diagnostic details.

The central ERROR NOTIFIER pattern supports five channels natively: Slack,
Telegram, WhatsApp, Gmail, and Discord. You can activate multiple channels
simultaneously—for example, Slack for immediate team visibility, email for
archival, and PagerDuty for critical production workflows. Each channel node
sits on a separate branch after the Error Trigger, letting you customize the
message format per channel. For a complete walkthrough of credential setup and
message templating, see the
Webhook node configuration guide.

How do you use n8n execution logs and the Error Trigger to debug workflow failures?

Open the failed execution from the direct URL provided in the error alert.
n8n displays each node with input/output snapshots; the failed node shows a
red indicator with the error message and stack trace. Click the node to inspect
the exact data that entered and the error that occurred. Combine this with the
Error Trigger’s lastNodeExecuted field to jump directly to the
failure point.

For persistent logging, set EXECUTIONS_DATA_SAVE_ON_SUCCESS=all
and N8N_LOG_LEVEL=debug as environment variables to retain
input‑output data even for successful runs. You can also build a diagnostic
workflow that queries the n8n API for all failed executions and logs them to
Google Sheets or Airtable for trend analysis—columns typically include
Timestamp, Workflow Name, Workflow ID, Execution ID, Failed Node, Error
Category, Severity, Error Message, Suggested Fix, Retryable, Status, and Notes.
For advanced monitoring with OpenTelemetry and centralized logging, see the
beginners node guide.

How does the Stop And Error node cause a controlled workflow failure with custom messages?

The Stop And Error node intentionally halts the current
workflow and throws an error, immediately triggering the linked error workflow.
It supports two operations: Error Message (a plain‑text string
for simple logging) and Error Object (a JSON object with
custom properties for structured error routing). Place it after an IF node to
fail the workflow when a specific business condition is unmet.

This node bridges business‑logic validation with error handling. For instance,
if an invoice total is zero or negative, route it to a Stop And Error node
with the message “Invalid invoice total.” The Error Trigger in the error
workflow receives this custom message in its error.message field,
enabling precise alerting and retry. For production use, combine Stop And Error
with error classification: use the Error Object mode to include a
category field (e.g., “validation_error”, “data_quality”) that
downstream Switch nodes use to route to different handlers. For complete
implementation details, refer to the
trigger nodes guide.