Monitoring and troubleshooting
When a request fails, this page helps identify the credential and stage responsible.
Four monitoring destinations §
Modern console monitoring has four destinations, each with a separate purpose:
- Health - Which credentials are available now and which ones are broken?
- Usage and Cost - How many tokens were spent and how much
- Request Log - Detailed record of each request
- Route Check - Given conditions, see how the gateway will choose
Health §
The Health tab shows current availability status of each Group and each credential and a consolidated list of issues requiring attention.
Meaning of credential status:
- Available - Normal participation in rotation
- In cooldown — Temporarily skipped after an upstream rate limit or error, then restored automatically when the cooldown expires.
- Blocked — Automatically removed after the consecutive-failure threshold. API-key Groups are periodically probed and restored after a successful probe; subscription credentials do not use this automatic recovery path.
- Deactivated - you manually turned it off and will not participate in the rotation
See How scheduling works for cooldown and blacklisting triggers and recovery behavior.
Problem credentials are collected in one list, so you do not need to inspect every Group.
Request log §
Every request is recorded and filterable by time, Group, model, and status. Opening an item shows the selected credential, protocol conversion, retries, and upstream response.
The few fields most useful when troubleshooting:
- Routing Identity - Which Group and credential this request actually goes to
- Protocol conversion - When the protocol used by the client is different from the upstream protocol, you can see the conversion process here
- Error details — a redacted, length-bounded summary to interpret together with the error code, origin, scope, and matched rule
See Errors and recovery for fields and codes, and Runtime settings for log retention.
Model consistency compares the model sent upstream with the model reported in the upstream response, before client alias rewriting. A conversation response without a reported model is unknown; a mismatch within an attempt is not overwritten by a later matching value. This does not change routing, retries, or pricing, and historical logs are not rewritten.
Streaming and non-streaming chat use output tokens divided by total request duration for average output speed. This includes waiting, retries, credential rotation and reasoning, rather than pure generation speed. Speed is unavailable when usage or duration is missing.
Streaming first response measures receipt of the first non-empty upstream SSE data line or WebSocket message, which may contain only metadata. It is not the time to the first visible word. A zero or missing value is shown as unavailable.
Client IP supports exact-match filtering. Its list column is hidden by default and can be enabled in column settings. Historical logs are not backfilled, and redacted exports anonymize addresses.
In Classic and Modern, the request log and usage pages offer auto refresh beside the refresh control. It is off by default, with 5, 10, 30, or 60 second intervals. Both pages and interfaces share the current browser preference across navigation and reloads; it is not a cross-device setting.
Auto refresh preserves filters, pagination, scroll position, open details, and chart selections; relative time ranges advance with each request. Hidden tabs pause and resume when visible, and busy pages skip a round. Failures retain the last result and stale-data warning, with retry backoff capped at 5 minutes.
When Record request bodies is enabled for an access key, individual log details show the original client body and allow copying it. Recording captures decoded inbound content before parameter overrides, request redaction, and protocol conversion. Responses WebSocket records each turn’s request frame. Upstream requests, upstream responses, and headers are not recorded.
Valid UTF-8 JSON up to 256 KiB is stored verbatim. Larger bodies truncate string values only, preserving JSON structure. Non-JSON bodies, bodies still too large after truncation, or bodies exceeding the pending-write budget retain only a state and original size, without content. Old logs and requests made while recording was off are not backfilled.
Administrators and sessions authenticated with the key that sent the request can read its recorded original body. Modern redacted log exports exclude bodies, but content copied from details is not thereby redacted; inspect it before sharing. Bodies follow request-log retention, and disabling recording does not clear history.
Route checking §
This is the fastest entry point for troubleshooting. Enter an AccessKey and model name to see whether the request can route, candidate Groups, available credential counts, or the reason routing fails.
Typical uses:
- "Why is it prompted that the model does not exist?" - The checker will tell you whether this model is open in the Group for which this key can be used.
- "Why are there no available credentials" - View the total number of credentials and the currently available number by candidate Group
- "A new group was added but it did not take effect" - Confirm whether the AccessKey is authorized to it
View route-inspection reasons and remediation →
Inspect candidate Groups and available credentials without sending a real request.
Usage and cost §
View request volume, success and failure trends, cache hit rate, token categories, and cost estimates, grouped by Group, model, AccessKey, and other dimensions.
Token categories directly affect cost:
- Non-cached input - Input token for normal billing
- Cache Read - the part that hits the cache, usually far cheaper than non-cached
- Cache Write - The cost of establishing cache, some service providers bill it separately
- Output - the token generated by the model, usually the most expensive
Therefore, a high cache hit rate is a good thing: for the same request volume, a higher cache hit rate substantially reduces cost.
Cost is estimated from upstream token usage, model prices, and the Group and AccessKey price multipliers for operational analysis and capacity planning; it is not equal to provider billing and cannot be used for financial reconciliation. Known gaps include requests without upstream usage, models without pricing data, and price changes that are not applied retroactively.
Data integrity §
The Usage tab includes a Quality metric. It measures not service quality, but how complete the statistical data itself is:
| Metrics | Meaning | Impact |
|---|---|---|
| Usage missing | Upstream did not return token usage | These requests are excluded from statistics and cost estimates |
| Usage section missing | Only returned partial dimensions | Cost is lower than the actual amount. |
| Unpriced cost | Has usage, but this model has no price data | Not counted in cost, usage is still recorded |
| Partial pricing | Only some token types have prices | Cost is too low. |
High values mean the reliability of cost estimation is declining. Unpriced usually indicates missing model pricing; see Model management.
Troubleshooting order §
Follow this order when troubleshooting; two or three steps usually identify the cause:
- Check your health first - Have all the credentials been cooled down or blocked? If so the problem is with upstream or the key itself
- Reuse route check - Are there candidate Groups and credentials available? If it doesn't work, it will tell you the reason directly.
- Finally, open the request log — find the failed request and inspect its error code and redacted summary
When you suspect one particular credential has gone bad, there is a more direct route: open the Group's credential page, run Test connection on it, and confirm on the spot with one real request; see Groups and channels.
If health is normal and route inspection finds candidate Groups and available credentials, the failure is probably upstream—quota, model removal, or regional restrictions. The request-log code and safe summary provide the next clues.