DeepSeek API Outage Lasts 4 Hours 52 Minutes: The Disaster Recovery Lesson Behind a Week's Consumption Compensation

On October 15, DeepSeek's chat service and two API models experienced a partial outage simultaneously, lasting 4 hours and 52 minutes. DeepSeek subsequently announced that it would fully refund the consumption amount of the past 7 days per account in the form of bonus credits. This incident exposed not only the stability issues of a single vendor, but also the disaster recovery challenge that all applications relying on a single model API must face.

What Was Interrupted and for How Long

According to DeepSeek^Ad's official status page, the incident was titled "DeepSeek Web/API Partial Outage" and affected three components: the chat service, the DeepSeek V4 Pro API service, and the DeepSeek V4.1 Flash API service. The timeline is recorded in UTC: investigation began at 00:11, root cause identified at 01:06, fix implemented and monitored at 04:49, and service restored at 05:04.

According to Caixin, the web and app began showing "server temporarily unavailable" from around 8:00 Beijing time, and the chat service became completely unavailable from 9:08. TechNode also confirmed that both the chat service and the two API models were affected. DeepSeek did not specify the exact cause of the failure, but its compensation notice mentioned that a comprehensive service stability review had been launched and that single points of dependency would be eliminated. A single failure taking down both the chat product and two API models simultaneously—this wording points to an issue with underlying shared components.

What Is "OpenAI-Compatible API Format"

After 2023, OpenAI effectively turned the /v1/chat/completions request and response structure into an industry-standard interface. The so-called "OpenAI-compatible format" means that third-party services have replicated this routing, field names, and return structure, so that SDKs, libraries, and code originally written for OpenAI can be used directly by only changing the base URL and model name. DeepSeek, Moonshot, Zhipu, Together, Groq, and even locally deployed vLLM and Ollama all provide compatible endpoints. This convention greatly reduces the cost of multi-vendor disaster recovery: switching no longer requires rewriting the calling layer; you only need to change variables in the code. However, it only guarantees consistency in "interface shape," not in output style, function calling support, context length, or rate limiting strategy—which is exactly what evaluation needs to backstop.

What Compensation Covers and What It Doesn't

According to The Paper and IT Home, the compensation terms are straightforward: the bonus credit amount equals the account's total consumption from October 8 to 14, automatically issued to API users as bonus credits. One detail on DeepSeek's pricing page has the greatest impact on the next bill: "When both recharge balance and bonus balance exist, the bonus balance is deducted first." In other words, once the bonus credit arrives, it will be consumed before cash.

There is a key misalignment here: compensation tracks your past consumption amount, not your actual loss. Accounts with high consumption from October 8 to 14 receive more, while accounts still in the prototype stage that week receive less—even if the October 15 outage happened to hit right on your launch day. Compensation also stops at the bill: requests your product failed to respond to, accumulated retries, and the resulting customer service tickets are all outside the scope of compensation. The notice did not state whether the bonus credit expires; it is recommended to check the balance page on the DeepSeek platform directly to confirm.

This Is Not the First Time Since September

According to Caixin statistics, since September DeepSeek has experienced 13 failures, most of which were performance degradations of the web and API, with 4 involving partial outages of the web and API. The October 15 status page showed that from July to October 2026, the V4 Pro API service availability was 99.74%, and the V4.1 Flash API service was 99.47%.

V4.1 Flash is a new model released by DeepSeek on September 10. The company calls it "the smallest model in the new architecture family" and provides it under the name deepseek-flash in the API. Some newsletters linked this string of failures to demand pressure from the new model, but DeepSeek officially has not confirmed this, so it can only be treated as speculation.

These data do not mean DeepSeek is particularly fragile. Any hosted model API has rough mornings. The real lesson is exactly what DeepSeek itself wrote in its notice: putting everything on the same dependency is a risk—if your application sends every LLM call to only one vendor, you face the same problem.

What Does 99.74% Availability Mean

A monthly availability of 99.74% is roughly equivalent to 1 hour and 52 minutes of unavailability per month (calculated based on 30 days per month, 43,200 minutes); 99.47% is roughly equivalent to 3 hours and 49 minutes per month. This is the "API layer" statistical scope, usually calculated by request success rate or time-slice weighting, and definitions vary by vendor. By comparison, mainstream cloud vendors' single-region SLAs are often above 99.9% (about 43 minutes per month), while top LLM services, due to reliance on GPU clusters, inference queuing, and frequent model version iterations, are generally lower than traditional cloud services. This means that concentrating all LLM traffic of a critical business on one model API makes annual cumulative downtime reaching the hour level almost the norm rather than the exception—this is the quantitative basis for the article's argument to add fallback.

Adding a Backup Provider for DeepSeek Calls

DeepSeek API documentation clearly states that its API is compatible with the OpenAI format, with the base URL https://api.deepseek.com, and demonstrates how to use it with the official OpenAI Node SDK. This makes the cost of a backup solution very low: change a base URL and model, then create another client.

Several choices in the code are deliberate:

• timeout and maxRetries are SDK options. A short timeout with a single retry prevents a dead endpoint from hanging your request for minutes before it's the backup's turn. The backup endpoint also sets the same limits, in case it is itself slow.
• Connection failures and timeouts are thrown as APIError subclasses without status, so status === undefined counts as an outage, as do 429 and 5xx.
• 400 or 401 does not trigger a switch. A malformed request or invalid key is your own bug; sending it to a second vendor would only mask the problem.
• The backup endpoint can be any OpenAI-compatible endpoint you already trust, configured via environment variables. Cost is not the primary consideration; whether it can hold up when DeepSeek goes down is.

It is worth noting that different models may give different answers. If you need to parse structured output, the backup model must also be evaluated. Also record which vendor served each request, otherwise you won't know how much traffic is running on the backup.

Why 400/401 Should Not Trigger a Switch

HTTP status codes can be classified by "whose fault it is": among 4xx, 400 (malformed request), 401 (invalid key), 403 (no permission), and 404 (model name does not exist) are all client-side issues. Resending to another vendor will only get the same error, and worse, it masks bugs in your code, configuration drift, or missed key rotation. In contrast, connection failures, timeouts, 429 (rate limiting), and 5xx (server errors) are transient vendor-side failures—the situations fallback should truly take over. This principle of "routing by error nature" is the common foundation of circuit breakers and retry strategies: fail fast on deterministic errors, and only apply backoff and failover to transient errors.

What You Can Do This Week

1. Open the DeepSeek platform balance page to confirm whether the bonus credit has arrived and how much it is.
2. Remember that bonus credits are deducted first, so the cash balance will remain unchanged for a period—adjust your consumption alerts monitoring the cash balance accordingly.
3. Review the logs from October 15 00:11–05:04 UTC and count the number of failed requests. This number is closer to the true cost of the outage, and compensation does not cover it.
4. Add fallback as described above, and in a staging environment point the primary endpoint to an erroneous URL to test whether the switch takes effect.

A More Fundamental Engineering Judgment

The core of system design is always about trade-offs: what you pay when each dependency fails, and what you pay in advance to survive that failure. The model API is just one item on this dependency list. October 15 is a reminder that it is worth designing in advance for its possible disappearance.

If your model caller is a coding agent, then this should also be considered in selection: whether it can switch between different agents, models, and accounts by task, and whether it can seamlessly migrate a task to another when one agent reaches its usage limit. Multi-vendor disaster recovery should not just be a patch at the API layer, but also a capability of the toolchain itself.

Dependency Inventory and "Substitutability" Design

Mature systems typically maintain a dependency inventory, annotating each item: failure probability, impact scope, whether there is a degradation path, and recovery time objective. The model API is just one item, alongside databases, identity authentication, CDN, and message queues. An often overlooked dimension is "substitutability"—not only whether interfaces can be replaced, but also whether data formats, evaluation benchmarks, billing methods, and account quotas can be smoothly migrated. This is especially true for coding agent scenarios: task state, conversation history, and tool calling protocols are often bound to a specific agent, and the migration cost when switching is much higher than changing an HTTP endpoint. Treating substitutability as a selection metric means reserving cost for "this vendor disappearing tomorrow" during procurement and architecture phases, rather than patching temporarily after a failure occurs.

One-line Summary

DeepSeek's October 15 outage lasted nearly 5 hours and it fully refunded bonus credits, revealing the necessity of disaster recovery for a single model API.

Paragraph Summary

On October 15, DeepSeek experienced a simultaneous partial outage of its chat service and two API models, V4 Pro and V4.1 Flash, lasting 4 hours and 52 minutes. The company fully refunded the consumption amount from October 8 to 14 per account as bonus credits. The article points out a key misalignment: compensation tracks past consumption rather than actual loss, and requests the product failed to respond to, retries, and customer service costs are not covered. Bonus credits are deducted before cash balance. Since September, DeepSeek has had 13 failures, and V4 Pro and V4.1 Flash had availability of 99.74% and 99.47% over the past four months, respectively. The author advocates leveraging DeepSeek API's OpenAI format compatibility to add a backup provider fallback, and provides specific engineering rules: switch only on connection failures, timeouts, 429, and 5xx, not on 400/401; backup models need re-evaluation, and record which vendor served each request.