DeepSeek outage on November 7: chat and API partially unavailable for 45 minutes

On Saturday, November 7, 2026, DeepSeek recorded a partial interruption of its Web and API services. The official incident page gives a window of 07:11–07:56 UTC, or 45 minutes, and marks the incident resolved. For teams that build on the API, the useful question is what their applications did during that window.

What happened to DeepSeek on November 7?

DeepSeek categorized the event as “Web/API Partially Unavailable.” The affected components listed on its status page include the DeepSeek V4 Pro API, DeepSeek V4.1 Flash API, chat service and search service. The status update says a fix was implemented and monitored before the incident was resolved. It does not identify testing of a new model as the cause.

Some users reported a “server busy” response or DeepSeek Messages stream ended before message_stop. These describe what a user or client observed; they are not evidence of the underlying cause.

Was this caused by DeepSeek V4.1 Pro testing?

The official incident record does not confirm that theory. A Saturday outage and rumors about a future model are insufficient to establish a deployment or test as the cause. The incident should be described as a partial outage until DeepSeek publishes a root-cause explanation.

Why can 45 minutes matter to an API application?

A person can retry a chat. An application may have customer requests, support workflows, scheduled jobs and agents waiting on the same upstream. Streaming is particularly awkward: the client may receive the beginning of a response, then lose the stream before the final marker. Retrying without knowing whether an action completed can duplicate work.

An availability comparison also needs care. 99.9% over a 30-day month corresponds to about 43.2 minutes of full downtime. This incident was labeled partial, so its 45-minute duration is not automatically an SLA breach for every customer. The impact depends on the affected calls, the contractual definition of availability and the measurements from your own application.

What should developers do when DeepSeek is unavailable?

For personal use, keep important output locally and a second tool available for deadline work. For API products, prepare the response ahead of time:

1. Set timeouts and bounded retries. Exponential backoff with jitter helps prevent synchronized retry traffic.
2. Distinguish 429, 5xx and incomplete streams. Rate limits, service faults and truncated responses require different handling.
3. Use a circuit breaker and queues where appropriate. Do not let one unavailable dependency hold the entire product open indefinitely.
4. Test another provider path. A different base_url may still lead to the same upstream. Check prompts, tools, output format and cost on the alternative model.
5. Measure user-visible failures. Track latency, empty outputs and streams that stop early alongside HTTP error rates.

Can MandAPI fix an upstream outage?

A gateway cannot restore DeepSeek's own service. A multi-model catalog can help teams prepare routes to other providers before they need them. The MandAPI public catalog, checked November 8, 2026, lists DeepSeek models and families from other providers. A catalog status is not a guarantee of continuous upstream availability.

If your app depends on DeepSeek, select an alternative for each task, test its behavior and implement the switching policy in your application. See Models for available options and Pricing for current costs. Our November 3 incident report gives an earlier example of the same operational need.

Frequently asked questions

Is DeepSeek still down?

The November 7 incident is marked resolved on the official incident page. For a decision right now, check current status and make a test request from your own environment.

How long did the interruption last?

DeepSeek's official record gives 45 minutes, from 07:11 to 07:56 UTC on November 7, 2026.

Did V4.1 Pro testing cause it?

DeepSeek did not state that cause in the incident record. The connection remains unconfirmed.

Does a gateway automatically fail over?

That depends on the product configuration. Multiple available models make alternatives possible, but your application still needs a tested switching policy and criteria for quality, cost and errors.