n8n Error Workflow: Catch, Retry & Alert on Execution Failure

An n8n error workflow is a dedicated workflow that activates automatically whenever another workflow fails during execution. It starts with the Error Trigger node—which must be the first node in the workflow—and receives a JSON payload containing the failed workflow’s full execution ID, error message, stack trace, and the identifier of the last node executed. You configure each production workflow to point to a shared error handler through its Settings panel, creating a centralized failure‑management layer. [1]

How does the Error Trigger node start an error workflow in n8n?

The Error Trigger node is the gateway: when any workflow linked to this error handler fails, n8n sends a structured JSON payload into this node and executes whatever nodes follow it. You place it as the first node of a new workflow and then assign that workflow as the error handler in another workflow’s Settings. [2]

The Error Trigger receives fields such as execution.id, execution.url, error.message, and lastNodeExecuted. When the failure originates in the main workflow’s trigger node (not a later node), n8n delivers a separate trigger object with a WorkflowActivationError event. One error handler can serve many workflows—each workflow simply selects it in Options → Settings → Error Workflow. Because the Error Trigger only fires on automatic executions, you cannot test it by clicking “Execute Workflow” manually; activate the main workflow and let a real error occur. For customizable failure messages, use the Stop And Error node, which intentionally terminates the workflow and forwards a custom error object to the Error Trigger [3]. For a deeper view of how triggers classify workflow starts, see n8n trigger types explained.

How do you build retry logic with exponential backoff in an n8n error workflow?

Exponential‑backoff retry in n8n uses an Error Workflow that catches the failure, calculates a growing delay, then re‑triggers the original workflow. A Set node computes the wait time using the formula min(maxDelay, baseDelay × 2^(attempt−1)), and a Wait node pauses execution before the retry call. [4]

The approach classifies errors into retryable (408, 409, 425, 429, 500, 502, 503, 504) and non‑retryable (400, 401, 403, 404, 422) categories. It also adds random jitter (±25%) to prevent retry storms and stops after a configurable maximum number of attempts. For manual intervention, the workflow suspends at a Wait node after all retries are exhausted, then optionally proceeds to a Stop And Error node so that a global error workflow can capture the final failure. For real‑world orchestration patterns beyond retry, consult n8n use cases for production automations.

How do you send a Slack alert when an n8n workflow fails?

After the Error Trigger, chain a Set node to format the message with the workflow name, execution ID, error message, and a direct link to the failed execution, then connect a Slack node configured with your workspace credentials. The Slack node posts the formatted message to a specified channel immediately. [5]

A typical message reads: “⚠️ Workflow ‘Invoice Sync’ failed. Execution ID: 231. Error: Connection timeout. Last node: HTTP Request.” The execution URL lets responders jump directly to the failed execution log. Many teams route failures into a dedicated #n8n-errors channel, keeping operational noise separate from general chat. For more on branching failures by severity—such as only sending high‑priority alerts to SMS while low‑priority ones go to email—see n8n IF & Switch node branching guide.

How do you send an email notification from an n8n error workflow?

Add an Email (SMTP) or Gmail node after the Error Trigger in your error workflow. Populate the subject with the workflow name and error type, and the body with the error message, stack trace, execution URL, and timestamp. Use a Set node upstream to assemble the HTML or plain‑text content before passing it to the email node. [4]

Production teams often send HTML‑formatted emails with sections for “What failed,” “Where to investigate,” and “Suggested fix.” The execution URL is clickable, eliminating hunting through logs. You can also attach the raw error JSON as a plain‑text file for further analysis. For complete observability patterns including logging to Google Sheets alongside alerts, review n8n node techniques for data formatting.

How do you use n8n execution logs to debug workflow failures?

Open the failed execution from the execution list or the direct URL provided in your 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. [1]

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. For advanced monitoring with OpenTelemetry, check n8n architecture & scaling strategies.

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

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) and Error Object (a JSON object with custom properties). Place it after an IF node to fail the workflow when a specific business condition is unmet. [3]

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.” This allows downstream alerting and retry while also logging the specific reason for failure. For more on the Error Trigger node that receives these messages, revisit the types of n8n workflows hub.