This is a methodology and data-coverage reference, not a live API performance report. It explains how the Chat-Deep.ai DeepSeek reliability project classifies observations, what its public files contain, and which conclusions the available evidence does not support.
API coverage limitation: the dated daily snapshot reviewed on September 4, 2026 contains no eligible authenticated API measurements. It cannot establish API availability, generation speed, or an outage. This page makes no commitment to continuous API monitoring, scheduled results releases, or a future 30-day report.
Chat-Deep.ai is independent and is not operated by, endorsed by, or affiliated with DeepSeek. For a current service problem, consult DeepSeek’s official status page and our separate independent DeepSeek availability monitor, taking account of each source’s scope and timestamp.
Available evidence and its limits
The worked example below is the source snapshot labelled September 3, 2026, generated at 2026-09-04T00:21:16.570Z. It is one dated file, not a cumulative history or a statement about service health now. The counts were checked against its summary and observation rows.
| Evidence in that snapshot | Measured attempts | Excluded checks | What it supports |
|---|---|---|---|
| Authenticated API: catalog and two streaming probe definitions | 0 | 1,725 | Insufficient data. No API success rate or latency conclusion. |
| Official home-page HTTP check | 575 | 0 | Reachability of that public page from the named probe locations; not a logged-in chat test. |
| Official status JSON check | 575 | 0 | Whether the feed was reachable and its published status indicator met the configured contract; not independent confirmation of all services. |
| Chat web entry-point HTTP check | 0 | 575 | No eligible observation of this path in this snapshot. |
| Developer-platform entry-point HTTP check | 0 | 575 | No eligible observation of this path in this snapshot. |
The 1,150 measured attempts belong to the home-page and status checks, not authenticated API calls. The API exclusions are labelled monitor_invalid. That label alone does not identify a credential, balance, or configuration root cause, and it is not a DeepSeek outage measurement. Zero eligible API rows in this file also does not mean that earlier files never contained API measurements.
Timestamp boundary: eligible observations in this file span 2026-09-03T00:00:15.475Z to 2026-09-03T23:59:59.920Z. Four excluded rows fall just after midnight, up to 2026-09-04T00:00:00.539Z. A source-day label is not a substitute for inspecting each row’s actual UTC timestamp.
- Dated summary JSON: September 3, 2026
- Dated observations CSV: September 3, 2026
- Most recently available summary JSON and rolling observations CSV — these links can change independently of the dated example above.
What the probe definitions actually test
The published methodology separates HTTP reachability, authenticated API contracts, and provider-published status. These are different evidence types, with separate denominators. A home page loading successfully does not prove that a user can sign in, send a chat message, or generate an API response.
| Probe definition | Test boundary |
|---|---|
official_home, official_chat_web, developer_platform | Bounded HTTP requests to public entry points. They do not execute the browser application, authenticate a user, or exercise every feature. |
official_status | Retrieval of the official Statuspage JSON and evaluation of its published status indicator. Incident history remains a separate publisher-supplied source. |
api_models | An authenticated model-catalog request. A successful catalog response is not a successful generation request. |
api_chat_completion_flash, api_chat_completion_pro | Tiny synthetic streaming requests checked for an exact response marker and a terminal stream marker. They do not assess general answer quality, long-context tasks, or load capacity. |
The released definitions distinguish Flash and Pro paths. A probe name is not evidence that a valid call occurred: eligibility and counts must be checked in the relevant file. The reviewed dataset contains no Vision Exp observations, and no results on this page should be generalized to Vision or to an untested model. This is not a current model catalog; see our model-name reference for that separate topic.
Collection design and provenance
The project’s first released observation is recorded at 2026-08-06T00:23:34.468Z — August 5 in the operator’s Pacific time zone. This is the origin of the released record, not proof of uninterrupted collection since that moment.
- Cadence: the source design schedules regional runs every 15 minutes. A configured schedule is not proof that every expected run completed; use actual observation timestamps and inspect missing slots.
- Locations: the reviewed snapshot names
ap-south-1,ap-southeast-1,eu-central-1,sa-east-1,us-east-1, andus-west-2. These are AWS observation points, not universal country coverage or the physical locations of DeepSeek’s servers. - Request profile: the published streaming test uses a fixed synthetic English prompt and a bounded output. Version 1.0 keeps one primary outcome per probe in a scheduled run; a later success does not replace an earlier failure.
- Privacy: the published observation schema contains bounded measurement metadata rather than visitor conversations, API keys, authorization headers, or generated response text. No new API requests were run for this September 4 editorial revision.
Pre-launch exclusion: the source methodology records an August 5–6 validation problem with the public status custom domain. Those affected rows were excluded from the released results and collection start; the corrected probe uses the underlying official Statuspage JSON endpoint. The exclusion is a monitor-validation correction, not an independently observed provider outage.
How to interpret success, exclusions, and gaps
Within an unchanged probe and reporting window, the observed success rate is 100 × successful eligible attempts ÷ all eligible attempts. Skipped checks enter neither side of that fraction. With zero eligible attempts, the result is “insufficient data,” not 0% or 100%.
| Recorded state | Treatment in the published method |
|---|---|
| Configured contract passes | Eligible successful observation for that specific probe, time, and location. |
| API credential/configuration prevents a valid test | Excluded as skipped or monitor-invalid, not counted as a provider-availability failure. |
| Automated web/status access is blocked | Recorded separately as monitor-blocked where the method applies that classification; not treated as provider downtime. |
| Eligible timeout, network failure, HTTP 429/5xx, or failed response contract | A measured failure under the method; the classification alone does not prove internal root cause or global impact. |
| Missing scheduled row or missing numeric value | A gap or unavailable value. JSON null and an empty numeric CSV cell are not zero. |
Do not combine API, web, and status checks into one headline “DeepSeek uptime” figure. The source retains an overall rollup for audit purposes, but marks it as unsuitable for the headline. A percentage without its probe definition, eligible count, exclusions, and time window is incomplete evidence.
Timing fields are not interchangeable
The data dictionary defines latency_ms as total bounded request duration and first_byte_ms as time to the first received byte or event. For streaming chat, ttft_ms measures the first non-empty content or reasoning token. For non-chat HTTP probes, the same field holds first-byte timing, not a generated-token measurement. This distinction also applies to the source table below.
The published aggregation uses nearest-rank p50 and p95 values from eligible, non-skipped observations with available timings. Excluded rows can retain request-duration metadata without becoming valid API performance measurements. The client does not separately measure DNS, TCP connection, or TLS negotiation. Timings reflect the configured workload and network path; they do not establish inference-only speed, performance for all users, or which region is “best.” No API timing conclusion is available from the dated example with zero eligible API attempts.
Inspect the available source files
The optional panel reads the most recently available daily source summary; it does not initiate an API test. Its own report day and generation time govern the values it displays. It may differ from the dated example, and an available file does not guarantee that collection is still running or complete. Missing and old data are labelled; no missing rate is estimated.
Inspect the most recently available daily source snapshot
Read each row as a named probe observation. API catalog checks are not chat generations; non-chat TTFT values represent first-byte timing. This panel is not a live-service verdict.
| AWS region | Check | Measured | Successful | Skipped | Observed success rate | Latency p50 | Latency p95 | TTFT p50 |
|---|---|---|---|---|---|---|---|---|
| ap-south-1 | api_chat_completion_flash |
0 | 0 | 96 | Insufficient data | — | — | — |
| ap-south-1 | api_chat_completion_pro |
0 | 0 | 96 | Insufficient data | — | — | — |
| ap-south-1 | api_models |
0 | 0 | 96 | Insufficient data | — | — | — |
| ap-south-1 | developer_platform |
1 | 1 | 95 | 100% | 640.1 ms | 640.1 ms | 639.9 ms |
| ap-south-1 | official_chat_web |
1 | 1 | 95 | 100% | 581.2 ms | 581.2 ms | 581.1 ms |
| ap-south-1 | official_home |
96 | 96 | 0 | 100% | 721.4 ms | 923.7 ms | 704.1 ms |
| ap-south-1 | official_status |
96 | 96 | 0 | 100% | 787.1 ms | 944.8 ms | 786.5 ms |
| ap-southeast-1 | api_chat_completion_flash |
0 | 0 | 96 | Insufficient data | — | — | — |
| ap-southeast-1 | api_chat_completion_pro |
0 | 0 | 96 | Insufficient data | — | — | — |
| ap-southeast-1 | api_models |
0 | 0 | 96 | Insufficient data | — | — | — |
| ap-southeast-1 | developer_platform |
1 | 1 | 95 | 100% | 904.9 ms | 904.9 ms | 904.7 ms |
| ap-southeast-1 | official_chat_web |
1 | 1 | 95 | 100% | 860.3 ms | 860.3 ms | 860.1 ms |
| ap-southeast-1 | official_home |
96 | 96 | 0 | 100% | 1,000.5 ms | 1,201.0 ms | 979.9 ms |
| ap-southeast-1 | official_status |
96 | 96 | 0 | 100% | 1,061.6 ms | 1,357.7 ms | 1,057.4 ms |
| eu-central-1 | api_chat_completion_flash |
0 | 0 | 96 | Insufficient data | — | — | — |
| eu-central-1 | api_chat_completion_pro |
0 | 0 | 96 | Insufficient data | — | — | — |
| eu-central-1 | api_models |
0 | 0 | 96 | Insufficient data | — | — | — |
| eu-central-1 | developer_platform |
1 | 1 | 95 | 100% | 739.9 ms | 739.9 ms | 700.2 ms |
| eu-central-1 | official_chat_web |
1 | 1 | 95 | 100% | 820.7 ms | 820.7 ms | 820.4 ms |
| eu-central-1 | official_home |
96 | 96 | 0 | 100% | 835.4 ms | 1,050.0 ms | 818.5 ms |
| eu-central-1 | official_status |
96 | 96 | 0 | 100% | 954.8 ms | 1,197.4 ms | 954.6 ms |
| sa-east-1 | api_chat_completion_flash |
0 | 0 | 96 | Insufficient data | — | — | — |
| sa-east-1 | api_chat_completion_pro |
0 | 0 | 96 | Insufficient data | — | — | — |
| sa-east-1 | api_models |
0 | 0 | 96 | Insufficient data | — | — | — |
| sa-east-1 | developer_platform |
1 | 1 | 95 | 100% | 619.8 ms | 619.8 ms | 619.6 ms |
| sa-east-1 | official_chat_web |
1 | 1 | 95 | 100% | 781.1 ms | 781.1 ms | 781.0 ms |
| sa-east-1 | official_home |
96 | 96 | 0 | 100% | 921.8 ms | 1,151.2 ms | 905.2 ms |
| sa-east-1 | official_status |
96 | 96 | 0 | 100% | 926.2 ms | 1,057.7 ms | 925.2 ms |
| us-east-1 | api_chat_completion_flash |
0 | 0 | 96 | Insufficient data | — | — | — |
| us-east-1 | api_chat_completion_pro |
0 | 0 | 96 | Insufficient data | — | — | — |
| us-east-1 | api_models |
0 | 0 | 96 | Insufficient data | — | — | — |
| us-east-1 | developer_platform |
1 | 1 | 95 | 100% | 899.8 ms | 899.8 ms | 899.5 ms |
| us-east-1 | official_chat_web |
1 | 1 | 95 | 100% | 980.4 ms | 980.4 ms | 980.2 ms |
| us-east-1 | official_home |
96 | 96 | 0 | 100% | 973.0 ms | 1,207.5 ms | 951.4 ms |
| us-east-1 | official_status |
96 | 96 | 0 | 100% | 862.1 ms | 1,168.3 ms | 860.7 ms |
| us-west-2 | api_chat_completion_flash |
0 | 0 | 95 | Insufficient data | — | — | — |
| us-west-2 | api_chat_completion_pro |
0 | 0 | 95 | Insufficient data | — | — | — |
| us-west-2 | api_models |
0 | 0 | 95 | Insufficient data | — | — | — |
| us-west-2 | developer_platform |
1 | 1 | 94 | 100% | 800.3 ms | 800.3 ms | 800.2 ms |
| us-west-2 | official_chat_web |
1 | 1 | 94 | 100% | 760.5 ms | 760.5 ms | 760.4 ms |
| us-west-2 | official_home |
95 | 95 | 0 | 100% | 913.4 ms | 1,027.2 ms | 847.3 ms |
| us-west-2 | official_status |
95 | 95 | 0 | 100% | 915.3 ms | 1,078.8 ms | 902.2 ms |
Interpretation: a successful observation means the configured check passed at that time and location. It does not prove that every DeepSeek user, endpoint, or network path was available.
- Version-pinned measurement methodology
- Version-pinned observation data dictionary
- Public project repository — code and reproduction details, not proof that every deployment or scheduled check is currently operating.
What this reference does not claim
This page publishes no current API availability verdict, no complete 30-day uptime figure, no service-level guarantee, and no regional performance ranking. An elapsed calendar window alone cannot establish a measured result: the underlying eligible observations and gaps would still need review. There is no scheduled release or monitoring-expansion commitment.
Provider incident reports remain attributed to DeepSeek and cannot fill gaps in independent observations. One failed probe does not establish a global outage. For help interpreting your own API response, use the error-code guide; for implementation context, use the API guide. Neither replaces direct evidence about a particular incident.
Frequently asked questions
Is this an official DeepSeek reliability report?
No. It is an independent Chat-Deep.ai methodology and data-coverage reference. Official status information is attributed to DeepSeek and is distinct from the project’s synthetic observations.
Does “insufficient data” mean the API was down?
No. It means there are too few eligible measurements to support the stated result. In the reviewed September 3 daily file, all 1,725 API checks were excluded and zero were measured; no API success rate can be calculated.
Can I use this page as a live API monitor or a 30-day uptime report?
No. The page does not promise continuous API monitoring or publish a complete 30-day result. Dated source files describe only their recorded probes and windows.
Why keep the methodology if new API tests are not being run for this update?
The source definitions, dated files, exclusion rules, and timing limits let readers inspect what was actually recorded and avoid treating missing data as success or failure. That documentary value does not require a claim of continuous monitoring.
Editorial revision — September 4, 2026: this page was reframed as a methodology and data-coverage reference. Continuous-monitoring and future-release promises were removed; the public source records were not changed. The revision date is not a new measurement date.