Example
Reviewing traces after a spike in latency
A walkthrough of debugging a slow or expensive production call using Traces, Analytics, and Annotations together.
Scenario
The Dashboard's average latency stat looks higher than usual. You want to find out which calls are slow, why, and flag anything worth fixing.
Steps
- Open Analytics and check the daily cost trend and cost-by-model breakdown for anything that spiked recently.
- Open Traces, sort by scanning the Latency column, and open the slowest recent trace.
- On the trace detail page, look at the span timeline — is the time going into
retrieve_context,llm_generate, orpostprocess? That tells you whether the bottleneck is retrieval, the model call itself, or your own code. - Check the Cost and Tokens stat tiles next to Latency — a slow call with unusually high output tokens often means the model rambled instead of answering directly.
- If the trace looks genuinely problematic, open Annotations and rate it "bad" with a note describing what you found, so it's flagged for whoever looks at prompt quality next.
Tip
Cross-reference the trace's
route and model metadata against the Analytics "requests by route" chart — a single slow route across many models often points to a retrieval or infrastructure issue rather than the model itself.