Performance

Trace explorer

The trace explorer lets you inspect individual proxy calls in detail. Use it to debug failed calls, verify routing behavior, and examine the full context of any request that passed through the platform.

Search by trace ID

Every proxy call is assigned a unique trace ID. If you have a trace ID from a log, error report, or another analytics view, paste it into the search field to jump directly to that specific call.

Filters

Two filter controls narrow the trace list. The proxy type filter limits results to a specific protocol (A2A, MCP, ACP, or REST). The status filter limits results to a specific HTTP status category (2xx, 4xx, or 5xx). Combine both filters to find, for example, all failed MCP calls.

Paginated trace list

The trace list shows matching calls in reverse chronological order. Each row displays the trace ID, timestamp, proxy type, caller agent, target agent, and HTTP status code. The status code is color-coded: green for 2xx, amber for 4xx, red for 5xx.

Traces are paginated server-side with 25 entries per page. Use the pagination controls at the bottom to navigate. The total count of matching traces is shown above the list.

Expanding a trace

Click any trace row to expand it and see the full details of that call. The expanded view provides all metadata recorded during the proxy relay.

Field	Description
Caller agent	The agent that initiated the call (name and permanent ID)
Target agent	The agent that received the call (name and permanent ID)
HTTP status	Response status code returned by the target endpoint
Latency	Round-trip time in milliseconds from proxy send to response received
Error message	Error details if the call failed (empty for successful calls)
Connection source	How the call was routed: direct, schedule, pool, or broadcast
Metadata	Additional context such as proxy type, request size, and response size

Using traces to debug failed calls

When investigating a failed call, the trace explorer is your primary tool. The expanded trace shows the exact error message, the HTTP status code, and the latency, which together tell you whether the failure was a timeout, a target-side error, or a proxy-level issue.

Filter to failures

Set the status filter to 4xx or 5xx to see only failed calls.

Identify the pattern

Look for clusters of the same error code targeting the same agent.

Expand a trace

Click a failed trace to see the error message and latency details.

Check the target

Cross-reference the target agent with the agent uptime timeline to see if it was offline during the failure window.

If the error message shows a timeout but the latency is under the proxy timeout threshold, the issue may be at the DNS or TLS layer rather than the target endpoint itself.

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