How does Rius detect swallowed errors in AI agents?

Rius detects swallowed errors with its pre-defined Swallowed Error alert, which fires when a run reports success even though a step inside it failed. It checks finished traces for a root span that ends OK while at least one child step that is not a tool call ended with an error. You can narrow the alert to one root service, and you can turn it off but not delete it. It is one of the detectors described in Pre-defined alerts, part of Alerts.

How it works

A swallowed error is an error that your code caught somewhere between the failing step and the root of the run, so the run looks successful. Rius looks for exactly that shape.

• What it checks: the root span of the trace finishes OK, and at least the configured number of child steps ended with an error. The default is 1.
• What does not count: errored tool calls. A failed tool call is returned to the model as the tool’s result, so the agent saw the failure and could act on it.
• When it fires: once per run, and only after the trace has finished. A run still in flight never fires early.
• Window: finished traces are scanned over a rolling time window, 5 minutes by default.
• Renotify: off by default, so the notification is sent once. Turn it on to repeat the notification every N minutes while the firing is open and unacknowledged.

The alert is built to catch cases like these:

• A model call inside the run fails and the code falls back to a canned answer instead of surfacing the error.
• Retries are exhausted and the code falls back to a cached value rather than failing loudly.
• A sub-agent in a multi-agent pipeline crashes and the orchestrator ships whatever partial answer it already had.

The alert was formerly called Silent Failure. The Rius MCP server still accepts silent_failure for it, and always answers swallowed_error.

Set it up

1. Send traces to Rius. The alert needs finished traces that contain the errored child spans, so initialize the SDK in your agent.

   import rius
    
   client = rius.init(
       api_key="ri_...",
       service_name="my-agent",
   )

2. Open the Swallowed Error alert on its details page. It is already there, so there is nothing to create. Check the time window and decide whether to turn on renotify.

3. Attach a channel so firings reach you. Rius delivers alerts to webhook, email or Slack.

4. To change how many errored child spans one run needs, set it through the Rius MCP server as min_errored_spans. The details page does not offer this knob.

5. To watch only part of your workspace, narrow the alert. On the alert’s details page, click Narrow this alert under Narrowed versions. This is an admin action. Give the copy a name and a Root service, which is the service of the run’s root span, then tune it on its own page.

6. If you do not want the alert, disable it. You cannot delete a pre-defined alert.

A narrowed version is a separate rule:

• It has its own page, settings, attached channels and firings, listed under Narrowed versions on the original alert’s page.
• It counts against your plan’s alert-rule limit, like a custom alert.
• Changing its filters resolves its open firings, because it now watches something else.
• The original alert keeps running as before, unless you disable it.

Use a narrowed version when one service needs its own delivery, for example a critical agent whose firings go to a dedicated channel.

What you get

• Runs that look healthy but hid a failed model call, an exhausted retry or a crashed sub-agent now raise an alert.
• One firing per run, so a single bad run does not flood your channel.
• No false alarms from tool errors the agent already saw, and none from runs that have not finished.
• A separate copy of the alert for one root service, with its own settings and channels.
• A detector that is always available: you can disable it, but it stays in the product so you can turn it back on.
• A firing history on the alert’s details page, so you can see which runs were affected.

When something else fits

• If a run fails visibly, with the root span itself ending in error, the Swallowed Error alert is not the one to use. The Consistent Error Pattern alert groups repeated errors by service, step and message across runs.
• If you want a threshold on cost, tokens, latency or error rate, use a custom alert instead.

Related