Introduction
The Traces switcher answers the most basic operational question there is: how much is running, and is it working. It is the view to read first, because every other number in Monitoring is only interpretable against volume.
Where to find it
AI Governance > Monitoring > Traces. Scope with the agent picker, bound with the time range.
The tab shows trace count, error rate and latency (p50 / p99) for the selected range, per day.
What this view answers
Question | Read |
Is anything running at all? | Trace volume — zero is a real answer and often the important one |
Is volume normal? | The shape over the selected range. There is no previous-period comparison — use a wider range to see what normal looks like |
Is it failing? | Error rate |
Is it slow? | Latency — p99 against p50, the tail rather than the typical run |
Why volume comes first
Every other Monitoring number is a ratio in disguise. Errors matter relative to runs; cost matters relative to runs; latency matters relative to what the agent is being asked to do.
Read in the wrong order, the same data misleads badly:
Errors doubled is alarming until you see volume tripled — the error rate improved.
Spend is up forty percent is a finance conversation until you see volume up forty percent — then it is arithmetic.
Everything is flat and healthy is reassuring until you notice volume is zero and has been for two days.
Note: A flat, quiet Traces view is ambiguous, and the ambiguity matters. It is equally consistent with well-behaved agents and with agents that have stopped sending. Before reading anything into a quiet chart, check the registry for agents sitting in
Setup Pending— see Agent Statuses.
Reading latency honestly
Averages hide the runs users actually complain about. An agent whose mean response time is steady while its slowest runs get slower has a real regression that the average will never show.
Look at the tail, and treat a growing gap between typical and worst as the signal. The usual causes are findable in an individual trace: a retry loop, a tool that has become slow, or a context that has grown.
Errors are the one unambiguous number here
An error is a run that failed. Unlike quality, it needs no judgement to interpret — which makes it the best starting point when something looks wrong and you do not yet know what.
What errors do not tell you is whether the agent did the right thing. An agent that completes every run successfully and answers wrongly has a perfect error rate. That is Evaluation's question, not Monitoring's — see Evaluation Overview.
"Monitoring can tell you an agent finished. Only evaluation can tell you it should have said that."
Where to go from a finding
Narrow to one agent — A fleet aggregate absorbs a single agent's spike. The scope picker is how you confirm which one — see Scoping: All Agents vs One Agent.
Open that agent's Observability tab — Monitoring aggregates; Observability lists the individual runs.
Read a trace from the affected window — The shape usually finds the cause faster than the content — see Reading a Trace.