Are errors actually hurting my AI agent runs?

Rius shows whether errors hurt your runs by putting Error rate next to Failed traces on each agent’s page. Failed traces are runs whose root span ended in error, so they are the runs that actually broke. A high error rate with few failed traces means your agent recovers, for example with retries or fallbacks. That costs time and money but does not break the result.

How it works

Two tiles on the agent page measure different things:

• Failed traces counts traces whose root span ended in error. The run did not complete.
• Error rate is the share of traces with at least one errored span, including runs that recovered.

A trace where a span errored but the agent recovered counts toward the error rate, not toward failed traces. For example, 18 traces with 3 recovered and 1 failed give 1 failed trace and a 22% error rate.

Each trace in Recent traces carries one of these states:

• completed: finished with no errored spans.
• recovered: at least one span errored, but the run’s root finished cleanly.
• failed: the run’s root span ended in error.
• running…: still running.
• frozen?: still running, but the instance running it has gone stale.

Read the two tiles together:

• Low error rate, few failed traces: errors are not hurting you.
• High error rate, few failed traces: the agent recovers. The errors are not breaking results, but retries and fallbacks add latency and cost.
• High error rate, many failed traces: errors end runs. Fix the cause first.

Trace figures count only finished traces, so a run shows up in them once every span of it has ended. A long session still in progress never skews the numbers. Running work shows under Open traces and as running… under Recent traces.

Rius also has a pre-defined alert named Swallowed Error (formerly Silent Failure). Pre-defined alerts can be turned off but not deleted.

Set it up

1. Send traces with the Rius SDK. If you followed the quickstart, your agent already appears on the Agents page. You do not register agents, because Rius finds them in your traces and heartbeats.
2. Open Agents and scan the Errors column. Rows with problems come first. Click the agent you care about.
3. Pick a time window in the top right: 15m, 1h, 1d, 7d or 30d. The tiles and every table below them use the same filter, so the numbers match the rows.
4. Compare Error rate with Failed traces in the summary and apply the reading above.
5. Tag your runs with a version, so you can see whether a release changed the failure picture. Set these in the environment:

RIUS_MAIN_AGENT_VERSION=prompt-v12      # the agent definition: prompt, tools, policy
RIUS_SERVICE_VERSION=2026.09.29-a41f3c  # the build or deploy

6. Open Versions and Compare to see failed rate and cost per trace side by side. Rius warns when either side has fewer than 20 traces, because the difference can be noise.
7. Check Drift for a rising failed rate over time. Each trace counts in the bucket it started in.

For the wider picture across agents, see Monitor AI agents in production.

What you get

• A direct answer to whether errors end runs or only slow them down, from two numbers on one page.
• A split of errored runs into recovered and failed, so you can tell a flaky tool call that retries from a run that never finished.
• Errored traces, the six newest traces with at least one errored span, covering both recovered and failed runs. View all in Traces opens the full list with the matching status filter.
• Exceptions, which groups errored spans by failure type, such as llm request failed or downstream span failed. Each group shows when it last happened and how many traces and spans it affected, so you can tell whether one cause or several are behind the errors.
• Drift charts for failed rate, cost per trace and time to first token, plus version comparison. You see whether the last release helped or hurt from the day it shipped.
• Click an instance ID anywhere on the agent page to show only that instance. This helps when one replica is behind the errors.

When something else fits

• Error rate and failed traces describe runs that already finished. If you need to know whether a process is alive, check Instances. Heartbeats show liveness, not progress, so a hung process that still sends heartbeats shows as running.
• If you want to be told when errors climb instead of checking the page, set up an alert on error rate or use the pre-defined Swallowed Error alert.

Related