Skip to content
Cloud Score Docs

Investigate a failed, blocked, or expensive request

Trace one request from its row in Observability to the decision card, its savings receipt and a Playground reproduction, then read what its error message means.

Observability › Requests with the Request drawer open: the request id with Copy id, View full request and View in raw data, then Request details and the start of Metrics.
The Request drawer in Observability: the request's recorded details, and further down the drawer the same stations the Playground showed.
On this page

The path

Start with a request ID or UTC incident window. Observability › Requests supplies the audit trail; its Request drawer and the full request page share the same recorded request evidence. A View in raw data link opens Signals scoped to that request.

Use the recorded status, route stages, attempts and cost before deciding how to change a key, model, policy or prompt. Missing evidence carries its cause instead of an inferred zero.

Find it in Observability

Open Observability, select the UTC range, then search by request ID, agent, model or environment, or narrow with Provider type, Model, Object, Requester, Status or API key. Failed requests and Most expensive are one-click shortcuts. The server sorts the time, token, list cost and provider latency headers and pages the result; Total and Displayed describe that result.

Observability › Requests with the Request drawer open: the request id with Copy id, View full request and View in raw data, then Request details and the start of Metrics.
The Request drawer in Observability: the request's recorded details, and further down the drawer the same stations the Playground showed.
  1. Open the request's row.

    The Request drawer shows loading until evidence arrives. Its UUID can be copied with Copy id. A trace=<uuid> URL opens the same record directly.

  2. Read Request details, Metrics and Attempts.

    Confirm the key, provider, selected model and status. A failed request can have no provider call, an earlier successful selection or several billed attempts; inspect each recorded fact independently.

  3. Open View full request if you need a dedicated page.

  4. Close when finished.

    Focus returns to the opener; direct deep links fall back to the table. Back and Forward retain the surrounding view.

Read the decision

Pipeline stations and guardrail verdicts shows recorded stages and their timing. A failed Attempt says failed and sits below the rail. Candidates and recorded decision shows the operative selection, candidate ladder, exclusions and mechanism modes. A final error is displayed separately from an earlier selection.

Quality tiers, affinity, axes and confidence can be unrecorded. Genuine zero measurements remain zero; unknown values state their cause. A selected candidate is not proof that a provider completed the request.

The ledger projects server amounts without recomputing savings. Negative amounts keep their sign. Read Classification and the key's Guardrails profile when routing or security evidence explains the result.

Read the recorded cost

Cost separates recorded list price, provider billable cost, estimate and overhead. Optimization and Cache show their own recorded evidence. Prompt Optimization distinguishes the requested choice from the prompt actually dispatched, and a cache or dedup response can involve no provider send.

On the full request page, the Overview tab ends with the Savings receipt, labelled Estimate: the reference model and its source, reference and actual cost, the routing, response cache and compression savings, known Cloud Score overhead and net savings, then the price card and whether the request was re-priced on reconcile. With no recorded reference model it claims no savings; View cost details opens the Cost & savings tab.

Reference-model savings, same-model prompt avoidance and provider cache-read discounts have different bases. Do not add them without a compatible server total. Cost increase (est.) is a negative saving; it remains visible in error ink. Unrecorded cache savings or token avoidance are unavailable, never fabricated zero.

The same request evidence in the drawer and the page

The Request drawer and the full request page share the same evidence composition. The drawer additionally loads its GitHub correlation: with more than 20 linked pull requests it shows the first 20 and a link to all of them in Signals. Supported external pull-request links open GitHub in a new tab.

Reproduce it in the Playground

  1. Recover the prompt from stored previews or your application.

    Request and response previews can be unavailable because storage is off, input was blocked by AI Security or documents were involved. The preview is a stored excerpt, not proof that a complete body is retained.

  2. Open Playground with the same platform key and constraints.

    Write Message, include the system prompt when appropriate, and use Routing and Advanced options. The key's profile controls guardrails. Document bytes stay in page memory and must be selected again after leaving.

  3. Review optimization before sending.

    Wait for known settings. With Prompt Optimization on, Optimize prompt prepares a comparison; choose Run original or Run optimized only after reviewing it. Off sends the original. An expired or changed comparison needs a new preparation.

  4. Inspect Result and Details.

    Read Routing, Decision and Usage for recorded evidence. A disconnected stream can be checked with Check request status without repeating generation. Use Copy ID in Details › Usage when reporting the accepted request; match its time and key in Observability.

Every generation is real

Sending a Playground request is billed and recorded like any other. Stop disconnects the browser stream; it does not cancel server execution or provider billing. Use the accepted request status for the final record.

What the error means

Recorded error or outcomeWhat to inspect
No enabled model matches capabilities or contextModels and Required capabilities; confirm an enabled model can satisfy the original request.
No candidates remain after constraints, policies or failoverCandidate exclusions, Max cost (USD), allow/deny policies and the final selection error.
Blocked by policy or budgetThe named policy or budget. A blocked request may never reach a provider.
Blocked or redacted by AI SecurityInput/output guardrail verdicts and the selected key’s profile; detector labels retain their canonical names.
Provider error / deadline exhausted / validation retryEach attempt and its provider error; repeated failure does not imply that no earlier selection occurred.
Missing or invalid API keyThe enabled platform key, its scope and header; a provider credential is not a platform key.
Stream closed before completionCheck request status or the Observability record. Do not infer cancellation or repeat the generation automatically.
Trace not foundThe ID and current workspace. The drawer closes with a notice and no event-dependent actions.

Server error text is rendered as text. Keep the displayed request ID when reporting a failure; do not share credentials or prompt contents unnecessarily. Troubleshooting describes setup failures.

What to check afterwards

  1. Check the incident period again in Observability.

    Use the same filters and UTC range, inspect completed/failed/blocked totals and refresh recorded evidence. Empty, filtered and past-last-page messages have separate actions. For latency or failure rates by the hour, open Gateway health.

  2. Compare recorded cost and latency on their stated bases.

    A smaller prompt alone proves neither lower total cost nor a faster end-to-end request. Use exact values and available coverage; retain unknown causes.

  3. Share the scoped request or Signals link.

    The URL restores the relevant view and request. Normal account and workspace verification still applies.

Related