Error Trigger
The Error Trigger (errorTrigger) starts an automation whenever another workspace automation ends in an unhandled failure. Use it to route failure alerts to Slack, PagerDuty, Jira, or email from one place instead of wiring error branches on every Step.
- Use it to
- Start an alerting or recovery automation when another workflow in the workspace fails
- Find it
- Tools → Start → Error Trigger
- Cost
- Free (0 Step credits for the trigger; downstream alert Steps use their normal rate)
- Limits
- Fires on unhandled workflow failures in the same workspace
- Output
- {{ 1.workflow.id }}, {{ 1.workflow.name }}, {{ 1.execution.id }}, {{ 1.error.message }}, {{ 1.error.stepNumber }}
- Instead
- Step error branch (Continue on error) when handling a single Step failure inside the same workflow
Workflow: "Lead Router" (wf_01h9...)
Failed Step 4: HTTP Request → 502 Bad GatewayA Live workflow in your workspace stops on an unhandled error (after any configured Step retries finish).
- Lives under Tools → Start and watches all or selected team automations in the workspace.
- Starts a separate alerting run when a watched automation ends in an unhandled failure.
- Groups repeated identical failures within a configurable Repeat cooldown window.
- Configured per Step in Test & Debug → If this step fails → Continue.
- Routes that specific run down a fallback branch so the automation can recover or clean up.
- Handled errors that let the run finish as Passed do not fire an Error Trigger.
Setting it up
Add the Error Trigger
Open Tools in the dock and select Error Trigger under Start. An automation with an Error Trigger cannot include other triggers.
Choose which automations to watch
Set Watch (scope):
- All workflows in this workspace (
allWorkflows, default): Watches every non-private automation in the workspace. - Selected workflows (
selectedWorkflows): Opens the Workflows (workflowIds) picker so you can select specific team automations.
Private automations are never reported. An Error Trigger only receives
events from team-visible automations (accessLevel: "team"). An automation
with an Error Trigger cannot be set to Private.
Choose which runs to watch
Select one or more run types in Runs to watch (origins):
| Option | Value | What it matches |
|---|---|---|
| Live runs | live | Automatic runs started by triggers or schedules while the automation is Live (selected by default). |
| Test runs started in Glow | manual_test | Manual runs started from the canvas dock (Run or Run from here). |
| Test runs from AI apps (MCP) | mcp | Whole-automation tests started via run_workflow_test from an MCP connection with the workspace secrets grant and no selected-workflow allowlist. |
Single-step tests, Subflow child runs, and runs of an automation that contains an Error Trigger never start another Error Trigger.
Set the repeat cooldown
Set Repeat cooldown (seconds) (dedupeWindowSeconds, 0 to 86400, default 300 seconds):
- The first failure for a
(workflow, stepNumber, errorCode or failureCategory)fires immediately withoccurrenceCount: 1and starts the cooldown window. - Identical failures during that window are counted rather than starting duplicate alert runs.
- The first matching failure after the window closes fires again with
occurrenceCountset to the suppressed count plus1. Set0to fire on every failure.
Test and go Live
Switch the automation to Live to start watching for failures. In Test & Debug, test against sample data, or pass sourceExecutionId over MCP testing from a failed team automation run.
What it passes on
If the Error Trigger is Step 1, downstream Steps read the failure payload directly:
| Reference | Type | What it holds |
|---|---|---|
{{ 1.workflow.id }} | Text | ID of the automation that failed. |
{{ 1.workflow.name }} | Text | Name of the automation that failed. |
{{ 1.workflow.url }} | Text (URL) | Direct link to open the failed automation on the canvas. |
{{ 1.execution.id }} | Text | Execution ID of the failed run. |
{{ 1.execution.url }} | Text (URL) | Direct link to open that failed execution in Glow. |
{{ 1.execution.origin }} | Text | How the run started: "live", "manual_test", or "mcp". |
{{ 1.execution.startedAt }} | Text (ISO 8601) | UTC timestamp when the failed run started. |
{{ 1.execution.failedAt }} | Text (ISO 8601) | UTC timestamp when the run failed. |
{{ 1.execution.durationMs }} | Number | Total run duration in milliseconds. |
{{ 1.failedStep.stepNumber }} | Number | Canvas Step number of the Step that caused the run to fail. |
{{ 1.failedStep.name }} | Text | Display name of the failing Step. |
{{ 1.failedStep.key }} | Text | Component key of the failing Step (for example httpRequest or integration/slack/send_message). |
{{ 1.failedStep.errorMessage }} | Text | Redacted error message (up to 1,000 characters, with workspace secrets and bearer tokens masked). |
{{ 1.failedStep.errorCode }} | Text | Machine-readable error code when reported by the Step. |
{{ 1.failedStep.failureCategory }} | Text | Classified category: "auth_expired", "rate_limit", "downstream_5xx", "schema_mismatch", "validation_error", or "other". |
{{ 1.occurrenceCount }} | Number | 1 on the first failure, or 1 + suppressed repeats when firing after a cooldown window with suppressed failures. |
Examples to copy
Slack incident alert
Post a rich alert to #ops-alerts whenever any Live automation in the workspace fails:
- Add Error Trigger at Step 1. Set Watch to All workflows in this workspace, Runs to watch to Live runs, and Repeat cooldown to
300. - Add a Slack Send a message Step at Step 2 with:
🚨 *{{ 1.workflow.name }}* failed at Step {{ 1.failedStep.stepNumber }} ({{ 1.failedStep.name }}) • *Category:* {{ 1.failedStep.failureCategory }} ({{ 1.occurrenceCount }}x) • *Error:* {{ 1.failedStep.errorMessage }} • *Inspect run:* {{ 1.execution.url }}
- Run
- Run a test in Test & Debug using sample failure data, or trigger an unhandled failure in a watched Live automation.
- You should see
- Step 1 outputs the failed workflow metadata, execution link, failedStep details, and occurrenceCount.
What’s Next?
- Configure per-Step retries and in-run fallback branches in Error Handling & Retries.
- Inspect full Step input and output payloads in Step-Level Executions.