How to set up an n8n error workflow for failed AI automations

Imagine an overnight AI classification workflow accepting a new record through its automatic trigger. The workflow reaches the classification step, fails and stops before the process can complete.

No responsible operator receives the error. By morning, the failed run is waiting to be discovered in n8n, while the team responsible for the workflow has no direct prompt to investigate it. The operator needs an alert that identifies the affected workflow and provides a safe route to the retained execution without copying the underlying record into email.

The practical fix is a separate n8n error workflow that begins with Error Trigger, receives failure data from the source workflow and sends a minimal-data alert to a named recipient. That gives the overnight classification workflow a clear handoff when an automatic execution fails.

An error workflow turns a failed automatic execution into an operational handoff. Instead of expecting someone to inspect n8n periodically, it routes the documented failure context to the person or team responsible for triage.

The route has two workflows:

1. The source workflow runs the AI-enabled process and can fail.

2. The error workflow starts with Error Trigger and sends the alert.

In the source workflow’s settings, you assign the second workflow as its error workflow. When an automatic execution fails, n8n starts the assigned route and gives Error Trigger information about the workflow and error. One error workflow can serve multiple source workflows, although ownership and alert content should make the source unambiguous.

This setup covers detection, notification and investigation. It does not provide retry logic, compensating transactions, deduplication, idempotency or an exactly-once processing guarantee. Those mechanisms affect business-state recovery and belong in a separate design.

Confirm the following prerequisites before changing either workflow:

• An existing source workflow has a safe automatic or production trigger that you can invoke under controlled conditions.

• Your n8n account can create or edit workflows and credentials and execute workflows in the relevant project.

• An approved SMTP account, authorized sender address and monitored recipient are available.

• Failed execution data is saved when the team expects alerts to contain execution IDs or links.

• The investigation window fits the configured execution-retention and pruning policy.

The documented project roles provide a useful access check. Project Admins and Project Editors can create, edit and execute workflows and credentials, while Project Viewers are read-only and cannot manually execute workflows. Role availability varies by n8n Cloud or self-hosted edition, so confirm the labels and capabilities in the deployed version against the n8n role documentation.

For self-hosted deployments, EXECUTIONS_DATA_SAVE_ON_ERROR controls whether error execution data is saved. The documented default is all, but operators should verify the active configuration rather than infer it. Retention also matters: pruning settings determine how long the failed execution remains available for investigation. Increasing retention can improve the investigation window while increasing storage use. See the documented execution environment variables for the relevant controls.

Obtain SMTP settings from the organization’s email provider or administrator. Host, port, encryption, app-password requirements, sender authorization, account policy, deliverability and service cost are provider-specific. Confirm these details before treating the route as operational.

Use a separate workflow so that alert routing remains distinct from the business process that failed.

1. Create the error workflow. Add a new workflow with Error Trigger as its first node. Give it an operationally clear name such as AI Workflow Error Handler.

2. Add Send Email. Connect Error Trigger to the documented Send Email node and select the Send operation. A failure alert does not need the response-waiting operation.

3. Create or select SMTP credentials. Enter the provider-approved user, password or app password, host and port. The SMTP credential documentation describes port 465 with implicit SSL/TLS and port 587 with STARTTLS. Use the combination required by your provider. Keep certificate validation enabled unless an administrator has defined a controlled exception.

4. Set the sender and recipient. Use an authorized From Email address and a monitored To Email address. A team mailbox or distribution list is useful when it has an explicit owner and established monitoring responsibility. For the overnight classification workflow, this should be the person or team expected to investigate a failed run rather than a mailbox with no named owner.

5. Add a recognizable subject. A reference expression is:

   Copy

   [n8n failure] {{ $json.workflow.name || 'Unknown workflow' }}
   

6. Create a minimal plain-text body. Use a fixed failure summary and fallbacks for the intentionally selected identifiers:

   Copy

   Failure: Automatic workflow execution failed
   Workflow: {{ $json.workflow.name || 'Unknown workflow' }}
   Last node: {{ $json.execution?.lastNodeExecuted || 'Unavailable' }}
   Execution: {{ $json.execution?.url || 'No saved execution link available' }}
   Diagnostic detail: Inspect the retained n8n execution. Raw error text is not included in this email.
   

   This implements the redaction boundary by replacing the raw error message with a fixed summary. Inspect raw error text in the access-controlled n8n execution rather than forwarding it by default. Treat the email as an alert, not a copy of the failed workload. Do not include prompts, model inputs, stack traces, credentials, customer records or other business data by default. Add a field only when the recipient needs it to identify, triage or open the failed execution.

7. Save the error workflow. The workflow needs to be available for selection from the source workflow settings.

8. Attach it to the source workflow. Open the source workflow, select Options > Settings, choose the new workflow under Error workflow, save the settings and then save the source workflow. This is the documented assignment path in n8n’s error-handling guidance.

SMTP alerts sent through this node arrive as separate conversations. The Send Email node cannot set the In-Reply-To and References headers required for email threading.

The adjacent comparison distinguishes the two documented Error Trigger payload shapes. Build expressions for both rather than assuming every failure provides the same execution fields.

Use fallbacks for values that may be missing. In particular, an execution ID or URL is available only when the corresponding execution data was saved, and these fields are not present when the failure occurs in the source workflow’s trigger node. A missing link should produce clear text such as No saved execution link available, not a malformed URL.

execution.retryOf appears only when the failed execution is itself a retry. It can provide useful investigation context, but it does not prove that retry handling is safe, complete or idempotent. Keep retry policy and business-state recovery outside the alert workflow.

Apply a minimal disclosure rule: the email should identify the workflow, state a fixed failure summary, identify the last executed node when available and link to the retained execution when possible. Raw error messages and detailed workload data stay in n8n under the platform’s access controls and retention policy rather than being forwarded by default.

Use a controlled failure to verify the complete path rather than checking the email node in isolation. For the overnight classification example, the test should exercise a safely isolated branch through the same type of automatic trigger the workflow normally uses, without processing a real business record.

1. Choose a safe test path. Isolate it from production side effects, or gate it with a dedicated test condition that normal data cannot satisfy.

2. Add Stop And Error temporarily. Configure the node with a recognizable, non-sensitive message such as CONTROLLED_ERROR_ROUTE_TEST. The Stop And Error node can deliberately fail an execution and pass custom error information to an error workflow.

3. Save the source workflow. Confirm that its error-workflow assignment still points to the route you created.

4. Invoke the source through its safe trigger. Follow the automatic-trigger requirement in the warning above. The invocation method depends on whether the source uses a webhook, schedule, queue, form or another production trigger.

5. Inspect the received email. Confirm the sender, recipient and subject. Check that the body identifies the correct workflow, contains the fixed Automatic workflow execution failed summary, reports the last node when available and links to the expected execution when available. Confirm that it does not contain CONTROLLED_ERROR_ROUTE_TEST, raw error text or unnecessary workload data.

6. Inspect the failed source execution. Open Executions from the instance overview or relevant project, filter by the source workflow and Failed status, and find the controlled run. Confirm the workflow, the CONTROLLED_ERROR_ROUTE_TEST message and the failed node. The Executions view shows executions from workflows the user can access.

7. Inspect the error-workflow execution. Confirm that the Error Trigger route ran for the same event and that its Send Email node completed successfully.

8. Match the evidence. Where an execution URL is available, confirm that the email opens the failed source execution containing the controlled test message. Where it is absent, confirm that the fallback text appears and that the retained record can still be found through the Executions view.

If no email arrives, inspect the error workflow’s execution history first. A failed SMTP node indicates an alert-route problem such as authentication, sender authorization, connection policy or recipient configuration. Diagnose that route before changing the source workflow’s business logic.

Rollback should remove both the routing assignment and the deliberate failure path.

1. Open the source workflow’s settings.

2. Remove the assigned error workflow or restore the previous assignment.

3. Save the source workflow.

4. Remove the temporary Stop And Error branch and any test-only condition leading to it.

5. Save the source workflow again and confirm that its normal production path no longer reaches the deliberate failure node.

This rollback prevents future failures from using the new route. It does not repair executions that have already failed.

Keep the failure domains distinct during diagnosis. A failed source execution means the business workflow stopped. A failed Send Email execution means the notification route could not deliver its message. Retained source and error-workflow records provide the evidence needed to separate those cases.

This configuration does not establish an independent secondary paging channel. If email delivery is business-critical, design and govern that additional escalation route separately rather than assuming the error workflow can report its own failure.

Assign one accountable workflow owner and one monitored recipient or team mailbox. The owner is responsible for the configuration and investigation path; the recipient is responsible for seeing and triaging alerts. Those responsibilities may belong to the same person, but they should be explicit.

Set a maintenance cadence appropriate to the workflow’s operational importance. SMTP credentials can expire, sender permissions can change, recipients can move roles, retention can be shortened and n8n roles or features can change after an upgrade or plan change. The error workflow can also fail independently of the source workflow.

Email-service usage and retained execution data can create ongoing service and storage costs. Balance those tradeoffs against the required alert volume and investigation window rather than copying settings from another environment. Teams formalizing this responsibility can include it in their wider monitoring and governance practice.

Start with a safe test copy of one of your existing workflows. Connect the error handler, assign a named recipient and trigger one controlled failure through the workflow’s automatic trigger. Before using the setup in the original workflow, confirm that the recipient receives the redacted alert and can use it to locate the failed execution.