How do I get alerted when my agent fails without raising an error?

Rius ships a pre-defined alert called Swallowed Error that fires when a step inside a run errored but the run still finished as a success. Enable it on the Alerts page and attach a channel, and each affected run opens one firing with its traces linked. If you want a threshold on error volume instead, you can build a custom alert.

How it works

The Swallowed Error alert looks at finished traces. It fires when the root span of a run finishes OK while at least the configured number of child steps, not counting tool calls, ended with an error. Somewhere between the failing step and the root, the code caught the error, so the run looks healthy.

Typical cases it catches:

• A model call fails and the code falls back to a canned answer.
• Retries run out and the code returns a cached value.
• A sub-agent crashes and the orchestrator ships a partial answer.

Errored tool calls do not count. A failed tool call goes back to the model as the tool’s result, so the agent saw the failure and could act on it.

The alert fires once per run. Only finished traces are evaluated, so a run still in progress never fires early. If a step in the run never errors, there is nothing for this alert to match.

The settings are:

The errored-span threshold is set only through the Rius MCP server, as min_errored_spans. The details page does not offer it. This alert used to be called Silent Failure. The MCP server still accepts silent_failure and always answers swallowed_error.

Rius evaluates a rule every minute while it has no open firing, and every five minutes while one is open, so timing is approximate to that cadence.

Set it up

1. Open the Alerts page and select Swallowed Error under Pre-defined alerts. Enable it. Configuring alerts is an admin action.
2. Attach a distribution channel to the alert. Rius delivers each firing to every channel attached to it: webhook, email or Slack.
3. Set the time window and Renotify on the details page. With Renotify off you get one notification per firing. Choose every N minutes, from 5 to 1440, to repeat until someone acknowledges it.
4. To watch one part of your workspace with its own settings or channel, click Narrow this alert under Narrowed versions. A narrowed Swallowed Error filters on Root service, the service of the run’s root span. It is a separate rule with its own page, and it counts against your plan’s alert-rule limit.
5. To alert on error volume as well, build a custom alert. A custom alert is one or more rules combined with AND over one shared rolling window, with optional filters. Metrics include Errors, Error rate and LLM error rate. For example:

FILTERS   Service = checkout-agent          (optional, applied before aggregation)
RULES     count(Errors) > 10
WINDOW    15 minutes                        (shared by all rules)

A custom alert thresholds on how many errors occurred. It does not check whether the run reported success, so use Swallowed Error for that case.

What you get

• One firing per affected run, opened the first time the condition matches. It resolves on its own after the condition has stopped matching for two hours. If the same condition returns later, it opens as a new firing.
• A firing page that shows when it opened, when it was last seen, the affected traces linked to the trace view, and a delivery list with one row per channel and the outcome of each attempt.
• View all in Traces on that page, which opens the trace list filtered to the firing’s signature and time window, so you can find the errored step inside the run that looked successful.
• A Firings page across the workspace, with the Open and Resolved tabs. You can filter it by Unacked only, Service, Step, title search and time window. The filtered view is a link you can share.
• Acknowledgment. Ack records who saw a firing and stops further notifications for it. The firing still resolves on its own when the condition clears.
• An optional root-cause report on the firing page when root-cause analysis is on, covering what failed, since when, and its reading of the cause.
• A count of open, unacknowledged firings beside Alerts in the sidebar.

When something else fits

• If your agent raises errors that repeat across runs, Consistent Error Pattern fits better. It groups errored spans by service, step and error message, and fires on the same error across distinct traces.
• If you care about a threshold on cost, tokens, latency or error rate rather than a hidden failure inside a successful run, use a custom alert.
• If the agent loops on one tool, Tool Loop watches for identical repeated calls in a trace.

Related