Real-time gateway checks, model historical success rates, no sample detection, and fault diagnosis. Includes complete inspection steps, practical verification, and error handling.

How to understand status monitoring

View the status page

Status monitoringProvides history of gateway detection, response time, and model requests. Page refreshes automatically, can be manually refreshed; If data is temporarily unavailable, it will show as unknown or expired, and will not default to normal settings.

Gateway inspection

The backend detects the gateway's public health interface every minute and records the last 60 times. A successful detection indicates that the gateway can respond, but it does not mean that all models or upstream can be successfully generated. Here, latency refers to the time spent on the health interface, not the time spent on the model initialization or full generation.

Model request history

Model cards come from real requests from native statistics on this site; Displays success rates over the past 24 hours, average response time, and hourly color bars. If there is a failure, some anomalies or anomalies will be displayed; Gray hours mean there are no records, so they cannot be counted toward success rates, nor do they mean downtime. If there are no new requests for a long time, it shows "No recent samples available," which does not guarantee current availability.

How to check for it

When the gateway is normal but the model is abnormal, first switch to the smallest text request and verify keys, balances, parameters, and upstream status. Historical failures include different request conditions and cannot be directly considered as independent probe availability. When the gateway detects anomalies, it retains time and errors and reviews them later.

The status page is not an SLA commitment, nor does it trigger paid model polling or collecting your prompt. Complete consumption information can only be viewed in the personal console.

Checklist before practical use

1. Prepare your own account and access keys, and do not use others' shared credentials.
2. Records client versions, systems, and models to be used for easy reproduction during troubleshooting.
3. Save the original configuration or screenshot, hide keys, verification codes, and private content.
4. Confirm that testing may consume a small amount of DK, starting with a single sentence and a single request.
5. Review the current model plaza and status page before deciding whether to enable more features.

Detailed investigation: gray is not failure, and green is not a guarantee either

Read the data update time first. The most recent successful gateway only proves that the inspection interface is accessible; Model statistics come from real, occurring requests. Only time periods with samples participate in the model's historical success rate; blank periods cannot be filled in as success. Historical failures may also be related to parameters, networks, or upstream, combined with error code analysis from your own request.

How to confirm that this section has been learned

Don't just check the "Configuration saved successfully" prompt. You should be able to clearly state the current Base URL, key usage, chosen model, and request protocol, and be able to verify your operation results on the corresponding console. The client-side tutorial uses a single actual plain text response and corresponding logs as the initial completion standard; Account tutorials are based on comprehensive security information; The billing tutorial uses the correspondence between principal, channel fees, and DK as the standard.

If an error occurs, record the occurrence time, HTTP status, content of the anonymized error, and the actual expected result. Do not screenshot the entire page key, and do not give the password or verification code to others. For 401, authentication should be resolved first; for 400, parameters should be resolved first; for 429, intensive retries should be stopped; for 404, request paths and upstream verification should be verified; recharging cannot resolve all errors.

A small task suitable for practice

Complete the minimum steps in this section in your own testing environment, recording in text "how you originally set it, which item you modified, and what results you saw." Do not treat production data, real payments, or irrecoverable commands as exercises. If you encounter features beyond what this section offers, first check the corresponding protocol tutorial before considering adding features; Changing only one configuration at a time makes it easy to judge which step leads to errors.

The next step is the boundary of the version

Return to the full learning map · Streamlined API site configuration · Real-time status of this site。

The tutorial was compiled on October 9, 2026. The specific interface and capabilities may vary depending on the client and upstream versions; The configuration guidelines do not mean that all client versions have passed the test. For balance payments, QQ / Alipay login, and open channels, please refer to the actual page page; Compression interfaces: Previously, upstream 404 and raw image channels were not available, so don't assume configuration files can be automatically removed.