Error Handling

Error handling lets you attach a fallback Action that runs when an Action run fails.

This is useful for alerting, cleanup, retries, or routing failed cases to a human review flow.

Where to Configure It

You can configure error handling at two levels:

• Action level: set an Error Action in the Action trigger settings.
• Step level: optionally override error behavior for a specific step.

When both are set, step-level configuration is used first for that failing step.

How Resolution Works

When a run fails, Studio resolves which Error Action to run in this order:

1. For confidence-related failures, a step-level confidence error Action (if configured).
2. Step-level error Action for the failed step (if configured).
3. Action-level Error Action from trigger settings.

If none is configured, the original run stays in Failed status and no fallback Action is started.

What Happens at Runtime

Error processing is asynchronous:

1. The original run finishes with Failed (or confidence-not-met).
2. A separate error-processing queue receives an error event.
3. The configured Error Action is started as a new run.
4. The Error Action receives failure context from the original run.

Because this is a separate run, you can inspect it independently in Runs.

Context Available to the Error Action

The Error Action receives structured context about the failed run, including:

• failed run id and action name,
• error message and stack trace (when available),
• failed step name,
• last successful step and output,
• original input parameters and input file metadata.

This makes it possible to send detailed notifications, open incident tickets, or perform targeted recovery logic.

Version Behavior

Error Actions follow the same run mode as the failed run:

• If the failed run was a manual/draft run, the Error Action runs as draft/latest.
• If the failed run was an automated run (webhook, schedule, trigger action), the Error Action runs as published.

Important Notes

• Automated error handling requires the target Error Action to be enabled and published.
• Error handling includes loop protection: failures inside an Error Action do not recursively trigger another Error Action run.
• Keep Error Actions small and deterministic (for example: notify, persist context, route for review).

---