How do I find agent runs that hit an error but recovered?

Rius badges a run as recovered when a child span errored but the root span finished without an error of its own. Filter the trace list to failed traces and look for the recovered badge. Open a trace to see the failed spans, the retry chains, and step through them one at a time. The errors stay counted, so you can see what your agent worked around.

How it works

Rius derives a trace’s status from its spans, so your agent reports nothing extra. A trace is failed when at least one span carries an OpenTelemetry ERROR status, normally a recorded exception.

A recovered run is a failed trace whose root span finished clean. Child spans errored, the agent retried or fell back, and the run itself completed. Only the verdict changes. The error count on the row and in the trace header still includes every failure.

How recovered differs from failed:

• Failed (no badge): the root span itself ended in error, so the run did not complete clean.
• Recovered: the root span ended clean, but one or more child spans errored.
• Recovered? (with a question mark): the root span never arrived, so Rius cannot see the root’s verdict and the badge is a guess.

The MCP trace tools expose the same split as two fields. status=Error with root_status=Ok is the recovered reading, and root_status=Error selects the genuine failures. A trace whose root span never arrived has no root_status.

Set it up

1. Open Traces and pick a time range. The presets are 15m, 1h, 1d, 7d (the default), 30d, and a custom range. The strip above the list sums up the traces that match your filters, including error rate.

2. Filter the status to failed. You can also click Add filter and combine the status with an agent, a user, or any attribute your agents send. Filters combine with AND and live in the URL, so you can copy the link for a teammate.

3. Read the status column. A row badged recovered is a run that hit errors and still finished. A row with a nonzero error count and no recovered badge is a genuine failure. Treat recovered? as unconfirmed until you open the trace.

4. Open a recovered trace. The waterfall shows the spans as a tree on a timeline, with failed spans highlighted along the path from the root to the error. Select an error span and the detail panel leads with the exception and traceback.

5. Look for retry chains. Back-to-back calls of the same tool or step collapse into one row, such as fetch_article · 3 attempts · recovered. Expand the row to see each attempt and which one succeeded.

6. Step through the spans. Use the previous and next buttons in the span panel, or the keyboard:

   • ]e and [e jump to the next or previous failed span.
   • j and k move to the next or previous span.
   • ]l and [l jump between LLM spans.

   Stepping keeps the open tab, so you can read the Input / Output of each call in turn. The URL keeps the selected span and tab.

7. To query the same split from an assistant, connect the Rius MCP server and ask for traces where the status is Error and root_status is Ok.

claude mcp add --transport http rius https://mcp.eu.console.rius-glassflow.com/mcp

The Exploring traces page covers filters, saved searches, the Spans tab, and the Map view in full.

What you get

• A list view where recovered runs are marked on the row, apart from clean runs and genuine failures.
• The full error record for each recovered run: error counts, the failing spans, and the exception with its traceback.
• Retry chains collapsed into one row with the attempt count, so a retry loop reads as one event.
• Fast navigation between failed spans with ]e and [e, with the Input / Output tab staying open so you can see what each call received and returned.
• Context growth and Since previous llm call views on a trace with several LLM calls, to check whether a retry changed the prompt.
• A saved search for a filter you reuse, visible to you or to the whole workspace.
• A shared view of the filtered list for a teammate. It is read-only and frozen, and it carries summary tiles and trace metadata only, never span content.

For how this fits into day-to-day monitoring, see Monitor AI agents in production.

When something else fits

• If you need a run that never finished, filter for running… instead. That status appears only when partial spans are enabled, and a trace stuck there long after the work should have ended points to a crash, a hang, or a killed process.
• If you only want the overall error rate and cost trend across many runs, the usage view gives the aggregate, and the trace list is for inspecting individual runs.

Related