OBSERVABILITY
Observe requests and recordings
Investigate a request using timing, usage, IDs, and optional captured content.
Overview
Use Observe to answer what ran, when it ran, how many tokens it used, what it cost, and where time was spent. Select the relevant time window and available model, key, member, or agent filters before comparing requests.
Open a request to inspect its details. Save the Netra request ID from your application's response header so you can correlate the same execution. A response object ID, agent label, trace ID, and request ID have different purposes; keep them separately.
| Observation | Interpretation |
|---|---|
| Prompt / completion tokens | Input and generated token counts; usage may be estimated when exact counts are unavailable. |
| Cached tokens | Reported input tokens served from a cache; a subset of prompt tokens. |
| Cost | Recorded usage cost; check the unit and model pricing when reconciling. |
| Duration | Elapsed request time. |
| TTFT | Time to first token; helps explain how long the caller waited before generation began. |
| TPOT | Time per output token; helps explain generation speed after it starts. |
| Trace | A linked agent run, when trace context and exported spans are available. |
Timing fields can be absent when they could not be measured or do not apply. Missing timing is not zero latency. Compare similar models, prompt sizes, stream settings, and output lengths; a mean value can conceal a small number of slow requests.
Recover a stalled view
Usage reads have a timeout so an interrupted request does not leave the view loading indefinitely. If an update fails, Observe shows Couldn't update usage and retries automatically while the view is active. Select Try again to retry immediately. It also refreshes after reconnecting or returning to the window. Existing values may remain visible while an update is pending; they are not proof of fresh data.
If a chart or trace cannot render, Couldn't display usage offers Try again to reopen the view while preserving your filters and search. These recovery controls do not require a page reload. If the problem continues, note the selected organization, time window and filters for investigation.
Optional request recordings
The Observe recording toggle enables request and response body capture for subsequent requests. Recording is off by default and changes can take about a minute to take effect. It is an organization setting restricted to permitted roles. Captures are best-effort, can be truncated, and are scheduled for deletion after 30 days. Switching recording off stops future captures; it does not retroactively erase already retained captures.
A historical request may have usage metadata without a recording because recording was disabled at the time, the recording expired, or capture did not succeed. Enabling recording cannot recover the past body. Request bodies can contain personal or confidential data; review what your application sends before enabling capture. Trace exports also require recording to be enabled.
Observe shows recorded inference usage; it is not a complete list of every HTTP attempt. Failures rejected before inference, such as invalid credentials or malformed requests, may have no usage entry. Empty results therefore cannot prove that an application sent no requests or experienced no errors. Keep safe client-side error logs for those failures.
The MCP exposes bounded metadata for requests, traces, and metrics. It does not return request/response recordings, span input/output, arbitrary attributes, or judge rationales. Use the dashboard with the appropriate access when investigation needs that content.