DeepSeek refunds a week of API spend after 4h52m partial outage

Nearly five hours of partial downtime

DeepSeek's status page logged a partial interruption on October 15, 2026 that ran from 00:11 UTC to 05:04 UTC — 4 hours and 52 minutes in total. The incident, documented in a dev.to write-up that compiles the timeline and Chinese-language reporting, listed three affected components at once: the consumer chat service, the DeepSeek V4 Pro API service and the DeepSeek V4.1 Flash API service.

The status page timeline shows the problem was flagged and under investigation at 00:11, the cause identified by 01:06, a fix deployed and being monitored at 04:49, and the incident declared resolved at 05:04. In Beijing the window ran from 08:11 to 13:04, the middle of a weekday morning. Caixin reported that the web and app interfaces began showing temporary-server-unavailable messages from around 08:00 local time, with the chat service fully offline from 09:08. TechNode separately confirmed the outage spanned the chat product and both API models.

DeepSeek has not said what actually failed. According to a customer notice reproduced by the outlet IT之家, the company has started a full review of service stability and plans to remove single points of dependency. That phrasing is consistent with the most notable detail of the incident: a chat product and two separate API model services failing simultaneously suggests something shared underneath all three.

A week of spend returned as credit

Later on the day of the outage, DeepSeek sent API customers a compensation notice. According to The Paper, it promises to return, in full, the amount each account consumed between October 8 and October 14, delivered as bonus credit and applied automatically.

The payout is tied to past spend rather than to actual losses. An account that burned through a lot of credit in the prior week gets a large refund; an account that was still prototyping gets a small one, even if the outage hit at the worst possible moment. The credit also stops at the bill — failed requests, piled-up retries and support load are not covered.

One detail from DeepSeek's pricing page affects the next invoice: when an account holds both topped-up cash and bonus balance, the bonus balance is deducted first. The refund will therefore be spent before any paid-in money. The notice as reported does not say whether the credit expires, so checking the platform's balance page is safer than assuming.

A rougher stretch since September

This was not an isolated event. Caixin counts 13 faults since September, most of them degraded performance on the web and API, with four involving partial outages of both. The status page's published uptime for July through October 2026 stood at 99.74% for the V4 Pro API service and 99.47% for the V4.1 Flash API service.

V4.1 Flash is the newest of the affected models. DeepSeek announced it on September 10, describing it as the smallest model in its new architecture family and serving it in the API as deepseek-flash. One newsletter has linked the string of incidents to demand for the new model, but DeepSeek has not confirmed that, so it remains speculation.

None of this marks DeepSeek as unusually fragile — every hosted model API has bad mornings. The interesting part is what the company itself wrote: a single shared dependency taking down multiple services is a real risk, and the same applies to any application whose every LLM call goes to one provider.

Why it matters

The credit is a strong gesture by API-provider standards — full reimbursement of a week's spend is well beyond most SLA payouts — but it compensates spending, not damage. For anyone building on DeepSeek, the outage is a prompt to measure the real cost: count the requests that failed between 00:11 and 05:04 UTC on October 15 in your own logs, confirm the credit arrived, and note that bonus balance burns before cash, which will skew any spend alerts watching the paid balance.

The structural lesson is redundancy. DeepSeek's API is compatible with the OpenAI format at its own base URL and works with the official OpenAI SDKs, which makes a second provider a cheap fallback: short timeouts, a single retry, and failover only on the errors an outage produces — connection failures, 429s and 5xx — while 4xx errors stay local because they usually indicate your own bug. Since a fallback model can answer differently, structured-output pipelines should be evaluated against it too, and each request should be logged with the provider that served it.