Monitor your surface

See request traffic in the Monitoring tab

Each surface has its own Monitoring tab, scoped to that surface alone, with several more charts below the one shown here.

Under SURFACES in the sidebar, select LLM, then open the surface you created in Create your first LLM Surface. Select the Monitoring tab.

Look for the following, updated in near real time:

• Summary cards: Main LLM, Judge, and Jury latency and token figures, plus total cost, for the selected window.
• Surface Traffic Over Time and Error Rate Over Time: request volume and the share of requests that failed.
• Connection Latency Over Time: response time at p50, p95, and p99.
• Token Usage Over Time: input and output token consumption for every request this surface handled, including the test calls from the previous guides.

Because metering runs per stage, a Judge or Jury on this surface shows its own latency and tokens in its own summary card, and its own share of the Total Cost breakdown, rather than being folded into one figure for the whole request. See Cost and usage governance →.

Read cost and usage from the response headers

Send any test request again, this time with curl -i to see the response headers:

curl -k -i -X POST "https://<YOUR_APPLIANCE_HOST><YOUR_SURFACE_ROUTE>/v1/chat/completions" \
  -H "Content-Type: application/json" \
  -d '{
    "messages": [
      { "role": "user", "content": "One more test request." }
    ]
  }'

A buffered response carries x-agent-stream-* headers: trace ID, provider, model, token counts, cached-token count, cost, cache hit or miss, and the ingress wire format the caller used. A client can read cost and usage figures directly from these headers without parsing the response body. A streamed response carries the request-time subset of the same headers. See Observability → for the full signal list.

Check the rejection breakdown

Still on the Monitoring tab, find the Rejections by category card. Every guardrail block that rejects a request is classified into a rejection category, with Uncategorized as the fallback, and counted here. A guardrail that only redacts a value or replaces it with a NER ID doesn’t reject the request, so it isn’t counted.

The redacted email request from Add guardrails and a budget does not appear here at all: redaction is not a rejection. If you send a request that Prompt Guard rejects, it appears in this breakdown. A usage-limit 429 is not a content rejection, so this card leaves it out.