Observability and Troubleshooting

Use the Token360 console to move from an account-level symptom to an individual request without exposing secrets or sensitive payloads.

Dashboard

The dashboard can report metrics such as request count, success rate, uptime, TTFT, end-to-end latency, throughput, token usage, cost, model mix, and error categories. Available dimensions depend on account type and the selected time range.

Use dashboard trends to answer:

Did the problem affect one model or all models?
Did failures begin at a specific UTC time?
Is the issue latency, rate limiting, validation, or provider availability?
Did request volume or token throughput change at the same time?

Requests and logs

Open a request from the Requests or Logs view to inspect available metadata, including model, status, timing, usage, cost, provider route, and correlation IDs. Prompt or generated content may be unavailable because of retention, privacy, archive, or account-policy settings.

For programmatic inspection, use generation metadata and billing reconciliation endpoints documented in the API Reference.

Correlation IDs

Capture these values whenever they are returned:

request or generation ID from the body;
X-Request-Id;
X-Trace-ID;
an asynchronous job, batch, image, or video resource ID.

These identifiers connect client logs, Token360 request records, billing records, and support investigation. Do not use an API-key secret as a correlation identifier.

Troubleshooting sequence

Validate the request locally. Confirm JSON, content type, endpoint, model name, and required fields.
Check authentication and policy. Confirm that the key is active, unexpired, allowed by IP policy, and authorized for the model.
Check spending controls. Review key limits, daily spend protection, wallet balance, and credit availability.
Classify the response. Use HTTP status, error.type, error.code, and optional service code.
Check scope. Compare another request and, when safe, another model to determine whether the failure is request-specific or broader.
Apply the documented retry rule. Retry transient errors only.
Escalate with evidence. Send timestamps and correlation IDs to support.

Common symptoms


`401`	Bearer header, key status, expiry, accidental whitespace, deleted key.
`403`	Model access, API-key IP rule, tenant IP policy, enterprise policy.
`402` or quota-related `429`	Wallet, credit, key spend limit, daily spend protection.
Capacity `429`	Request rate, token rate, concurrency, provider capacity; back off.
`400` after changing models	The new model's supported parameters and modality.
Stream stops early	Network path, client timeout, error event, final `[DONE]`; treat output as partial.
Async job stays pending	Queue state, submission status, polling interval, expiry estimate.
Output URL stops working	Signed URL expiry; request a fresh download URL where supported.

Support bundle

Include:

UTC start and end time;
public model name and endpoint;
request, trace, and resource IDs;
HTTP status and error codes;
whether the request was streamed;
sanitized request structure;
client SDK and version.

Do not include API-key secrets, authorization headers, passwords, payment details, or unredacted personal data.