By AI Promix Editorial Team · Documentation checked:
If your n8n Error Trigger is not working, check three things first: the failure came from an automatic execution, the monitored workflow has the correct Error Workflow selected, and the execution actually failed. Manual/editor failures do not automatically invoke the handler, and a node configured to continue may let the workflow finish successfully. These checks follow n8n’s Error Trigger documentation and node error settings.
This guide uses two disposable workflows to separate three questions: did the main workflow fail, did its handler run, and did the notification arrive? The examples are documentation-based and have not been executed in n8n.
Check why your error workflow did not run
Start with one identifiable failure. Match the workflow name, test time, and error message instead of comparing unrelated runs.
| Observation | What to inspect | Interpretation |
|---|---|---|
| No visible main-workflow run | Request URL, method, authentication, publishing status, and saved-execution settings. | Missing history alone does not prove that no execution occurred. |
| Main workflow succeeded | Published version, path taken, and On Error settings. | A handled node error may not have failed the overall execution. |
| Main workflow failed; no matching handler run | Automatic versus manual execution, selected handler, and handler-history visibility. | Check the routing configuration after ruling out missing records. |
| Handler failed in Edit Fields | Raw error input and expression previews. | Routing worked; mapping is the next failure point. |
| Handler failed in Slack | Credential, destination, message fields, and node error. | Routing worked; the notification step needs attention. |
| Handler completed and the message appeared | Match the message to this test. | The alert path worked for this particular case. |
Check successful handler runs too. n8n provides separate settings for saving successful and failed executions. A handler can succeed even though the workflow it monitors failed. Also check filters, retention, and access. Data redaction can hide node input/output; it does not by itself establish that a run never happened.
For workflows that use AI tools, choosing the architecture also means deciding where to inspect failures and approve actions. See how n8n Agents and AI Agent node workflows handle control and validation before redesigning your setup.
Build a small Error Trigger test
Record your n8n version and deployment type. You need permission to create workflows, publish the monitored workflow, inspect executions, and send to a Slack test channel using a working saved credential. Retain failed runs of the main workflow and both successful and failed runs of the handler where your settings permit.
We will use a separate handler for clarity. This is an example design, not a universal requirement: n8n also documents a self-referencing arrangement for workflows containing Error Trigger.
1. Create the handler: Workflow B
Name it “AI Promix Error Handler Test.” Connect Error Trigger → Edit Fields → Slack. In Edit Fields, choose Manual Mapping and add these four String fields. Set each value to expression mode.
{{ $json.workflow?.name || 'Unknown workflow' }}{{ $json.execution?.error?.message || $json.trigger?.error?.message || $json.trigger?.error?.cause?.message || 'No error message available' }}{{ $json.execution?.lastNodeExecuted || 'Not available' }}{{ $json.execution?.url || 'No execution URL available' }}
The message expression handles ordinary execution errors and trigger-stage
error data. Its || fallback also skips empty strings. These are
illustrative expressions for text fields, not a guarantee of compatibility
with every n8n version. Use the
expression preview
with representative input; a new handler may have no input to preview until
a test runs.
Configure the Slack node for Message → Send, select your saved credential and test channel, and enter this message using the new Edit Fields output:
n8n diagnostic failure
Workflow: {{ $json.workflow_name }}
Error: {{ $json.error_message }}
Node: {{ $json.failed_node }}
Execution: {{ $json.execution_link }}Confirm that the text field evaluates the expressions, rather than sending the braces literally. Send only the details you need, not the entire execution payload. Save or allow autosave as your interface supports. The Error Trigger handler does not need publication, according to the node documentation.
2. Create the monitored workflow: Workflow A
Name it “AI Promix Failure Test” and connect Webhook → Stop And Error. Keep Error Trigger in B for this example.
- Set the Webhook method to POST, keep its generated path, and choose Respond → Immediately.
-
In
Stop And Error, select Error Type → Error Message. Enter
AI Promix controlled Error Trigger testin the message field. Keep its error on a stopping path. - Open A’s Workflow Settings and select B under Error Workflow. Confirm the setting is saved.
- Publish A and confirm publication completed with the configured nodes.
Use disposable workflows with no customer or business actions attached. Authentication can be None for this isolated test; if enabled, include the corresponding authorization in your request. An unauthenticated test is not a production-security recommendation. Unpublish A when finished.
Current publishing documentation uses Publish; older interfaces may say Activate. Production runs use the published version, so confirm your node edits reached it. Settings-only changes are an exception: current documentation says n8n republishes those automatically. Do not confuse that exception with publishing a new workflow or changed nodes.
Test the production Webhook and inspect both workflows
Use A’s Production URL for the decisive test. Clicking Execute workflow or using the editor’s test-webhook path does not verify automatic Error Workflow routing. See n8n’s execution types.
Replace the placeholder below with A’s Production URL. Run this in a Bash-compatible shell, or send the equivalent POST and JSON body from an API client. The example assumes no Webhook authentication; add your configured authorization if required.
curl -i -X POST \
'PRODUCTION_WEBHOOK_URL_FROM_WORKFLOW_A' \
-H 'Content-Type: application/json' \
--data '{"test":"AI Promix controlled Error Trigger test"}'This command has not been sent to an n8n instance. After sending your request, inspect:
- A’s execution: did it reach Stop And Error and fail with the expected message?
- B’s matching execution: did Error Trigger receive that failure, and did Edit Fields produce the intended values?
- The notification: did Slack succeed, and is the matching message visible in the selected channel?
With Respond → Immediately, the HTTP reply precedes the later outcome. It does not prove that A completed successfully or that Slack delivered an alert. No separate Respond to Webhook node is needed for this response mode.
Handle missing error details and notification failures
The
Error Trigger payload documentation
distinguishes ordinary errors under execution from
trigger-stage failures under trigger.error. Execution ID and
URL require saved execution data and are absent when the main trigger fails
before normal execution. The retryOf field applies only to
retries.
That is why the mapping uses fallbacks. A missing execution link does not
mean the handler failed. After Edit Fields, the Slack template uses the
named outputs such as $json.error_message; it does not depend
on the original execution object being retained.
If B fails in Edit Fields, inspect its actual input and previews. If it fails in Slack, inspect the credential, channel, message configuration, and exact node error. If Slack reports success but you cannot find the message, check the destination workspace/channel and returned node data. Match records to this test before concluding that the full path worked.
For AI workflows, alerting and fixing the underlying failure are separate tasks. If the failure concerns the parser, use our guide to fix n8n’s “Model output doesn't fit required format” error.
Expected results for common test cases
These are documentation-based expectations and diagnostic interpretations, not observed n8n test results. The distinction between a failed execution and an internally handled error follows error-workflow behavior and the On Error options.
| Case | Expected behavior and check |
|---|---|
| Manual/editor failure | The assigned handler is not automatically invoked by that failure. |
| Production request reaches Stop And Error | A should fail and invoke selected handler B. Inspect both executions. |
| B is no longer selected in A | A can fail without this route to B. This example’s A contains no Error Trigger; restore the association afterward. |
| Continue handles a node error | If the remaining execution succeeds, do not expect failed-execution escalation for that handled error alone. |
| Continue (using error output) | A supporting node sends error data down its error output. Inspect the final execution status; a later failure can still matter. |
| B starts but its notification fails | A matching handler execution demonstrates routing, even though notification failed. |
| Synthetic input checks a fallback | It can check mapping for that input, but cannot establish real trigger-stage routing or delivery. |
Use a separate disposable variant and a node supporting the relevant setting for Continue tests. Restore diagnostic changes afterward. An in-process error handler is not a guarantee of detection for every host, process, or network outage.
Frequently asked questions
Can I test Error Trigger by failing a workflow manually?
Not its automatic routing. n8n documents that manual/editor failures do not automatically start the assigned Error Trigger handler. Sample input can help check mapping, but use an automatic execution to verify the connection.
Does the error handler need to be published?
No. The handler does not require publication for this role. In this example, publish the monitored Webhook workflow A and select B in A’s Error Workflow setting.
Why is there no execution URL in the alert?
The URL depends on saved execution data. It is also absent when the main workflow’s trigger fails before normal execution exists. Inspect the available payload and use a fallback instead of requiring the link.
Can several workflows share one error handler?
Yes. Select the same handler in each monitored workflow’s Error Workflow setting. Include workflow identity in the alert so you can identify which configured workflow failed.
Next step: run the controlled production test, match the execution records to your message, and use the diagnostic table to locate the failure. Unpublish the disposable monitored workflow when you finish.
Research method: This guide was checked against official n8n documentation on September 26, 2026. The workflows and expected outcomes are illustrative and were not executed in n8n. Check expression previews, available controls, and execution data in your installed version before relying on the alert.