Skip to Content
Rius

My AI agent fails without raising an error. How do I find the cause?

Rius shows an agent that fails without raising an error as a recovered trace: a child span errored, but the run’s root span finished clean. Open the Traces page, find the recovered runs, and follow the highlighted path from the root to the errored span, where the exception and traceback are the first thing in the detail panel. The Swallowed Error alert flags these runs for you as they finish. For the wider setup, see Monitor AI agents in production.

How it works

Rius derives trace status from the spans, not from what your agent reports. A trace is failed when at least one span carries an OpenTelemetry ERROR status. If the root span itself finished without an error, the trace gets a recovered badge. The errors are still counted. Only the verdict changes.

That is what a swallowed error looks like. Your code catches an exception, falls back to a canned answer or a cached value, and the run reports success. Rius still has the errored span, so it shows up in three places:

  • Traces: the recovered badge, and the failed status filter.
  • Agents: Error rate counts every trace with an errored span, including recovered ones, while Failed traces counts only runs whose root ended in error. A high error rate with few failed traces means the agent is recovering from errors, which costs time and money but leaves the result looking fine.
  • Alerts: the Swallowed Error detector fires when a trace’s root span finishes OK while at least one child step that is not a tool call ended with an error. It evaluates finished traces only, and fires once per run.

Errored tool calls are not counted by that detector. A failed tool call is returned to the model as the tool’s result, so the agent saw the failure. If a tool is your suspect, look at its span in the trace.

Set it up

  1. Find the runs. On the Traces page, add a status filter for failed and scan for rows badged recovered. A badge reading recovered? means the root span never arrived, so the verdict is a guess. Filters combine with AND and live in the URL, so you can share the exact list with a teammate.
  2. Check whether it is one cause or several. Open the agent on the Agents page. Compare Error rate with Failed traces, then read Exceptions, which groups errored spans by failure type, such as llm request failed, and shows when each last happened and how many traces it hit. Errored traces lists the newest runs with at least one errored span.
  3. Open one recovered trace. In the waterfall, failed spans are highlighted along the path from the root to the error. Select the errored span. For an error span, the detail panel leads with the exception and traceback. In Exploring traces, the keys ]e and [e jump to the next or previous failed span.
  4. Read what led to it. Back-to-back calls of the same step collapse into one row such as fetch_article · 3 attempts · recovered. Expand it to see each attempt. On an LLM span with captured messages, Since previous llm call on the Input / Output tab shows what changed in the prompt since the last call. If your SDK strips content, that tab says so, and timings, tokens and cost still show.
  5. Get alerted next time. Open Swallowed Error on the pre-defined alerts page, attach a channel, and set the time window and renotify. You can disable this alert but not delete it. An admin can narrow it to one root service, for example when a noisy service needs its own delivery.
  6. Tag versions. Set versions so the Agents page can show whether a release started the swallowing:
RIUS_MAIN_AGENT_VERSION=prompt-v12      # the agent definition: prompt, tools, policy
RIUS_SERVICE_VERSION=2026.09.29-a41f3c  # the build or deploy

With two or more versions, Compare on the agent page shows failed rate and cost per trace side by side, and warns when either side has fewer than 20 traces.

What you get

  • A list of runs that looked successful but contained errors, marked recovered, instead of a clean completed list.
  • The exact span where the error happened, with its exception and traceback, and the path from the root to it.
  • A grouped view of errors by failure type, so you can tell one broken step from several.
  • The earlier attempts and prompt changes that came before the failure.
  • A Swallowed Error firing for each run that finishes OK with an errored non-tool step, delivered to the channel you attached.
  • A version comparison that shows whether a new prompt or build raised the failed rate or cost per trace.

When something else fits

  • If the same error repeats across many runs in one service and step, the Consistent Error Pattern alert on the pre-defined alerts page is the better fit. If the agent repeats the same tool call with identical arguments, Tool Loop is.
  • If no span in a trace errored at all, the trace reads completed, so start from the Input / Output tab and the context growth strip above the span tree rather than from error filters.

Still stuck? Get help

Last updated on
Quickstart