Allow non-fatal errors to trigger Error Workflow (extend “Error / Stop and Error” node)

Feature Requests
, ,
1

The idea is:

Currently, the Error Trigger only runs when a workflow execution fails, and the Stop And Error node always terminates the workflow when it throws an error. This makes it impossible to use the official Error Workflow mechanism for non-fatal errors.
I’d like to request an enhancement to the existing Stop And Error node (or a new “Error/Warning” node) so that it supports two behaviours:

  1. Stop and throw error – current behaviour, marks execution as failed and triggers the Error Workflow.
  2. Continue and throw error – new behaviour, which sends an error event to the Error Workflow (via Error Trigger) without failing or stopping the main workflow.

In both modes, the node should allow defining custom error data (message, code, optional metadata) that is passed into the Error Workflow. This would let us use the built-in Error Trigger / Error Workflow for both fatal and non-fatal errors, instead of building custom sub-workflow solutions.

My use case:

I have workflows where I want to:

  • Log an error (or “warning”) in a central Error Workflow,
  • Include a custom message and structured data (e.g. API name, status code, payload snippet),
  • But continue the main workflow, either with a fallback path or simply by skipping a failing branch.

Concrete example:

  1. The main workflow calls an external API.
  2. The API sometimes returns 500 or times out.
  3. In that case, I want to:
  • Trigger my Error Workflow with a clear custom error like: “Primary API failed with HTTP 500 – using cached data instead.”
  • Then continue in the main workflow using a fallback (cached data, alternative API, etc.).

Today, if I want to use the official Error Trigger / Error Workflow, I have to end the execution (using Stop And Error or a real node failure). If I want the workflow to continue, I have to avoid the Error Trigger entirely and instead:

  • Use a Sub-workflow node to call a custom “error handler” workflow, or
  • Use Code nodes + sub-workflow logic to simulate an error log.

That splits my error handling into two totally different patterns: one for real failures and one for non-fatal errors.

I think it would be beneficial to add this because:

  • It enables centralized error handling for both fatal and non-fatal issues can use the same Error Workflow via the Error Trigger.
  • Workflows can log problems while still continuing with fallbacks or alternative paths.
  • Instead of custom Code + sub-workflow patterns, a single Error node can control whether to stop or continue and what error payload to send.

Any resources to support this?

  • n8n docs on Error Workflow and Error Trigger (shows that the error workflow only runs when a workflow fails):
  • n8n docs on the Stop And Error node (described as a way to stop the workflow and throw an error so the Error Workflow is triggered):

(These docs highlight that error workflows are tied to failed executions, which is exactly the behaviour this feature request would extend.)

Are you willing to work on this?

I’m not currently able to implement this in the core codebase myself, but I’m happy to:

  • Help refine the UX / configuration options,
  • Test early versions or previews,
  • Provide feedback on how it behaves in real workflows and suggest improvements.