Exploring traces

The Traces page shows every run your agents produce, from the list view down to a single span’s attributes. This page walks through finding a trace, reading its status, and inspecting it in the tree and map views.

Find the trace

Traces lists every trace in the workspace, newest first, refreshing automatically (the interval selector sits top right). Each row shows the time, status, the root span’s name, the agent that produced it, trace ID, span count, error count, token total, computed cost, and latency. Four more columns appear when the traces carry them: User (the end user), Sent by (who owns the API key that sent the trace), Instance, and Version (the agent version, or the build when there is none). Clicking a user, sender, or agent cell filters the list to it. The Spans tab is the same list at span granularity.

The time range 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: count, error rate, latency percentiles, tokens, and cost.

The Spans tab

Spans lists individual spans instead of whole traces, which is quicker when you are after one kind of step, say every tool call or every LLM call to a given model. Filter by kind with the All kinds menu (Agent, LLM, Tool, Retriever, Embedding, Chain, Other), by status, or with the same filters as the trace list. Click the Time, Tokens, Cost, or Duration header to sort. The search box matches span names, span IDs, trace IDs, and session IDs, so pasting a session ID lists every span in that session.

Clicking a trace ID opens that trace with the span highlighted. The Session link in a trace’s header opens Spans filtered to that session.

Search and filter

On Traces, the search box matches trace names and IDs within the traces already loaded, so load more pages to search further back. On Spans, it searches the whole time range, and also matches span IDs and session IDs. For anything else, build filters:

1. Click Add filter and pick a Field: a trace column, or any span or resource attribute your agents send. Each attribute shows how many spans carry it in the current window.
2. Pick an Operator: is, is not, is any of, is none of, exists, does not exist, and for numbers >, ≥, <, ≤, and between.
3. Pick a Value from the suggestions, or type one and use it as typed.

Each filter becomes a chip that you can edit or remove, and filters combine with AND. Attribute filters match exact values only; there is no partial match on attributes. Suggested values leave out payload attributes, such as prompts, completions, and tool input and output, and very long values, so type those if you need them.

Filters live in the URL, so a copied link opens the same filtered list. An attribute you have not declared is filtered as text and offers the equality and existence operators; declare it with a type to get the numeric operators and a readable label.

Filter from a span

In a span’s Raw tab, every attribute has a menu: Filter traces by this, Exclude this value, Copy key, and Copy value. Admins also get Declare this attribute…, which declares the key for the workspace with a type and a label guessed from the value.

Saved searches

Saved on the Traces filter bar keeps searches you come back to. Save current search… stores the filters, the search text, the status and agent selections, and the time range. A relative range such as the last 7 days moves with you rather than freezing to the day you saved it. Each saved search is visible to Only me, the default, or to Everyone in this workspace. Delete one from the same menu.

Trace status

Status is derived from the spans themselves rather than reported by your agent, and it has three values:

The third state goes by more than one name: the badge reads running…, the filter bar calls it incomplete, and the MCP trace tools report it as Incomplete. All three are the same thing, a span that has started and not ended.

Recovered runs

A failed trace whose root span finished without an error of its own is badged recovered: child spans errored, the agent retried or fell back, and the run itself completed clean. The errors are still counted, only the verdict changes. The MCP trace tools expose this as root_status, the root span’s own verdict, alongside status; 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, and the badge reads recovered? to say the verdict is a guess.

A run only ever reads as running… when partial spans are enabled. Without them a span reaches the platform once, at the moment it ends, so a run is invisible while it is in flight and a crashed run never arrives at all. With them enabled you see the run while it is still going, and if the process dies mid-run the last state it reported stays behind as running… rather than disappearing. That makes the status a useful filter in its own right: a trace still showing running… long after the work should have finished is a crash, a hang, or a process that was killed before it could report.

Waterfall view

Open a trace to see its spans as a tree on a timeline. Spans are badged by kind (chain, llm, tool), LLM spans show their token counts inline, and failed spans are highlighted along the path from the root to the error. The header summarizes the whole trace: duration, span and error counts, total tokens, and cost, plus the end user, who sent it, the session, the agent version, and the build when the trace carries them. The session links to every span in that session. For an error span, the detail panel leads with the exception and traceback:

Map view

The Map tab lays the same trace out as a graph, one node per span, with selectable lenses for latency, cost, tokens, and errors. Use it when the tree gets deep and you want to see where the time or money went at a glance:

Clicking a node in the map lands you on the tree filtered to that node’s spans, so the two views work as one: find the hot spot on the map, read its spans in the tree.

Tools on a trace

The trace page carries a few tools for the questions that come up once a trace is open:

• Retry chains. Back-to-back calls of the same tool or step, with the same input, collapse into one row, fetch_article · 3 attempts · recovered, when every attempt but the last failed. A retry loop then reads as one event instead of a wall of identical spans. Repeated calls that succeeded stay separate rows. Expand the row for the individual attempts.
• Context growth. For a trace with several LLM calls, a strip above the tree plots input tokens per call in order, which is where a runaway prompt or an unbounded history shows up first. Click a bar to select that call. A trace with more than 80 LLM calls groups neighboring calls into at most 80 bars, and the caption says grouped by N. Each grouped bar shows the run’s peak, and clicking it selects the run’s first failed call, or its peak when none failed.
• Compare runs. Compare the open trace against another run of the same agent, side by side, to see which steps changed, which were added or dropped, and where the cost or latency moved.
• Export. Download the loaded trace, or a single span, as JSON for a bug report, a test fixture, or offline analysis.

Inspect a span

Select any span to inspect it. LLM spans get a Model section computed from their OpenTelemetry GenAI attributes: provider, requested and response model, input and output tokens, and cost:

A call that reported no token usage shows a blank cost rather than $0, so it does not look free. When the model’s context window is known, the trace and the span also show how much of it was used, including reasoning tokens and the provider preamble.

The Input / Output tab renders the prompt and completion when the span carries content attributes; see attribute interoperability for the message shape. The Rius SDKs capture content by default, but if their privacy controls strip it, or your instrumentation never records it, the tab says so and the rest of the span (timings, tokens, cost) still works. Raw shows the span exactly as ingested.

On an LLM span with captured messages, Since previous llm call on the Input / Output tab switches the input to what changed since the trace’s previous LLM call. Runs of unchanged messages fold into one line, and each other message is marked added, removed, or changed, with the earlier version of a changed message under Before. When nothing changed, the tab reads Same input as the previous llm call. In an agent loop that mostly appends to one conversation, this shows what each step added to the prompt, and a dropped turn or a rewritten system prompt stands out.

Step through spans

The span panel has previous and next buttons for walking through spans one at a time, on the trace page and on the Spans tab. Stepping keeps the open tab, so you can read the Input / Output of each call in turn, and keeps your filters. The URL keeps the selected span and tab, so a copied link opens the same place.

The same moves work from the keyboard anywhere on the page, unless you are typing in a field. Press ?, or click the keyboard button, for the list:

The span tree on the trace page also works from the keyboard.

Share what you found

Share on the trace list creates a public, read-only link to a frozen window of the current view, useful for handing a failure to a teammate without adding them to the workspace. The link captures the time range, the status filter, and your filter chips at the moment you click, and the page it opens lists the filters it applies. The search text and the agent selection are not part of a shared view. The dialog takes an optional name and an expiry of 24 hours, 7 days, or 30 days, with 7 days as the default. The link is shown once, at creation; copy it then. Links are listed and revoked in Settings.

A shared view carries summary tiles and trace metadata only, never span content: no input or output previews, end user ids, instance ids, session ids, or the API key that sent a trace.

Next steps

• Monitoring usage and cost: the aggregate view of everything the traces show individually.
• Span attribute reference: the attributes behind the Model section and the Input / Output tab.