🇬🇧 EN

🚨 Error Trigger

The Error Trigger fires automatically whenever any other workflow in your Flusso account encounters a fatal execution error. It lets you build a single, dedicated error-handling workflow that responds to failures across your entire automation setup — sending alerts, logging details, or attempting recovery actions.

Category: Triggers · Type identifier: error_trigger

Overview

In any automated system, failures are inevitable. An external API might go down, a data field might be missing, or a step might produce an unexpected result that causes a downstream node to crash. Without an error-handling strategy, these failures are silent: you might not notice until a customer complains or a report is missing.

The Error Trigger solves this problem at a platform level. Rather than adding error handling logic to every individual workflow, you create one dedicated error-handler workflow that uses the Error Trigger as its first node. Every time any other workflow in your account fails, this error-handler fires and receives full details about what went wrong: which workflow, which run, which step, and the error message.

A typical error-handler workflow might send a Slack message to an operations channel, create a task in your project management tool, or send an email alert to the on-call engineer. More advanced error handlers can attempt to re-run the failed workflow automatically, or take compensating actions (such as cancelling a partially-processed order) to restore a consistent state.

Configuration

No configuration required. This trigger fires based on external events only — specifically, when any workflow in your account fails. There is nothing to set up.

Output Data

The Error Trigger provides detailed information about the failed workflow run:

Variable	Type	Description
`trigger.output.workflow_id`	String (UUID)	The unique identifier of the workflow that failed.
`trigger.output.workflow_name`	String	The human-readable name of the workflow that failed, as set in the workflow settings.
`trigger.output.run_id`	String (UUID)	The unique identifier of the specific run that failed. You can use this to look up the run in the Monitor view.
`trigger.output.step_key`	String	The key of the step within the workflow where the error occurred. Corresponds to the step key shown in the workflow editor.
`trigger.output.error_message`	String	The error message produced by the failed step. This is the same message shown in the run detail view in the Monitor.

// Build an error alert message using all available fields Workflow "{{ trigger.output.workflow_name }}" failed. Step: {{ trigger.output.step_key }} Error: {{ trigger.output.error_message }} Run ID: {{ trigger.output.run_id }}

Example Usage

Centralised Slack error alert

Create a single workflow that listens for all errors across your account and posts an alert to a Slack channel.

Create a new workflow called "Error Handler" and add an Error Trigger as the first node.
Add a Slack Message node. Set the channel to #ops-alerts and the message to:
:red_circle: *Workflow failed* *Workflow:* {{ trigger.output.workflow_name }} *Step:* {{ trigger.output.step_key }} *Error:* {{ trigger.output.error_message }} *Run ID:* {{ trigger.output.run_id }}
Set the Error Handler workflow to Active. It will now automatically post to Slack whenever any other workflow in your account fails.

Automatic retry orchestration

For workflows that call flaky external APIs, you can use the Error Trigger to attempt an automatic retry via the Flusso API:

Add a Logic Gate node after the Error Trigger. Check whether trigger.output.workflow_name matches the specific workflow you want to retry (so you don't retry every failed workflow).
On the true branch, add an HTTP Request node that calls the Flusso API to trigger a new run of the failed workflow, passing any relevant context.
On the false branch, add a Slack Message node to alert about failures in other workflows that you do not auto-retry.

Tips & Notes

Do not cause errors in your error handler. If the Error Trigger workflow itself fails (for example, because the Slack API is down), it will not trigger itself recursively — Flusso prevents Error Trigger workflows from firing on their own failures. However, you should still keep error-handler workflows as simple and robust as possible.

Only one Error Trigger workflow is recommended per account. You can create multiple workflows with Error Triggers, and all of them will fire on every failure. This can lead to duplicate alerts. It is usually simpler to have one error-handler workflow that uses a Switch node to route different workflows to different actions.
Fires on fatal errors only. Steps that are gracefully skipped or that return an empty result do not trigger the Error Trigger. It fires only when a step throws an unhandled exception that causes the run to be marked as failed.
The error-handler workflow must be Active to receive error events. A paused error-handler workflow will miss errors that occur during the paused period.

Related Nodes

Emit Event — emit a custom named event from one workflow to trigger another.
Event Trigger — fire a workflow based on a named event from another workflow.
Stop — explicitly terminate a workflow run with a success or failure status.