Performance

Trace explorer

The trace explorer is the ground-truth record of every call the platform relayed for your agents, across every lane. A trace is one call from end to end; a fan-out call, such as a broadcast, produces one trace with a leg for each delivery. Use it to debug failures, verify routing behavior, and examine any request in full.

Search by trace ID or agent ID

Every call gets a unique trace ID. Paste one from a log or an error report to jump straight to that call. The same field also accepts an agent ID — enter one to see every trace that agent participated in, as caller or target.

Filters

Two dropdowns narrow the list. The type filter limits results to one call type — Sync, Async, Broadcast, Pool, Scheduled, Relay, or Connector. The status filter limits results by outcome: Success (every leg succeeded), Partial (some legs failed), or Failed (every leg failed). Combine them to find, for example, every partial broadcast.

Paginated trace list

The list shows matching traces newest first, ten per page. Each row displays the short trace ID with a copy button for the full one, the timestamp, a color-coded type badge, the caller's agent ID (outside callers show as "external"), the leg count, how many legs succeeded and failed, and the total milliseconds.

Rows in the call quality card's activity log link here — clicking a trace ID there opens the matching trace in this card automatically. You can also link directly to a trace from outside the page by adding ?trace= and the trace ID to the page URL.

Expanding a trace

Click a row to expand it. A summary line shows the total duration, how many legs succeeded, whether a fallback was used, and which agent was slowest. Below it, a table lists every leg of the trace, ten per page for large fan-outs.

Leg column	Description
Agent	The agent this leg was delivered to
Status and duration	Whether the leg succeeded, plus its latency shown as a bar scaled against the slowest leg
Size	Request and response sizes in bytes
HTTP	The status code the target endpoint returned, red when 400 or above
Health	Whether the target agent was online or offline when the leg ran — failures during recorded downtime point at infrastructure rather than the application
Error	A plain-language description of what went wrong; hover it for the full message and the failure category

The export link at the bottom of the expansion downloads the complete trace — every leg, not just the visible page — as a JSON file for sharing or offline analysis.

Traces record who called, when, how large the request and response were, and how each leg ended. The content of the calls is never stored.

Using traces to debug failed calls

When a call fails, the expanded trace tells you where. The status code, the error description, the latency, and the health column together separate timeouts from target-side errors and infrastructure outages from application faults.

Filter to failures

Set the status filter to Failed — or Partial, if you are chasing incomplete fan-outs.

Identify the pattern

Look for clusters of the same error targeting the same agent, or search by that agent's ID.

Expand a trace

Open a failed trace to see each leg's status code, error, and latency.

Check the health column

If it says the target was offline, the fix is infrastructure; if the target was online, look at the application behind the endpoint.

If the error says timeout but the latency is well under the timeout threshold, the problem may sit at the DNS or TLS layer rather than the target endpoint itself.

For the complete guide to what an audit trail must capture — the metadata-only field reference, retention, and where compliance responsibility actually sits — read AI Agent Audit Trails: Prove Every Call Without Storing a Single Payload →

Switch to infrastructure metrics starting with fleet-wide health. See Fleet health and status heatmap →