DeepSeek's API Was Partly Down for 4h52m. It's Refunding a Week of Spend as Credit

• Book: System Design Pocket Guide: Interviews
• Also by me: Thinking in Go (2-book series) — Complete Guide to Go Programming + Hexagonal Architecture in Go
• My project: Hermes IDE | GitHub — an IDE for developers who ship with Claude Code and other AI coding tools
• Me: xgabriel.com | GitHub

---

If your code called DeepSeek's API between 00:11 and 05:04 UTC on October 15, it was talking to a service that DeepSeek's own status page marked as partially down. That is 08:11 to 13:04 in Beijing, a whole weekday morning there, and 17:11 to 22:04 on October 14 in California.

Later that day DeepSeek sent API customers a compensation notice. According to The Paper, it promises to return each account's spend from the previous seven days in full: "将按账号7日内（10.8-10.14）的消耗金额以赠金形式全额返还", which reads as "the amount consumed by the account over 7 days (10.8–10.14) will be returned in full as bonus credit."

That is a generous make-good. What it can't do is keep your app answering while the API is failing, and that part is still on you.

What broke, and when

The incident on status.deepseek.com is titled "DeepSeek 网页/API 部分中断" (DeepSeek web/API partially unavailable) and lists three affected components: the chat service (对话服务), the DeepSeek V4 Pro API service and the DeepSeek V4.1 Flash API service. Its timeline, in UTC on October 15:

• 00:11, investigating: "正在排查问题，以定位原因。" (investigating to find the cause)
• 01:06, identified: "已定位原因，正在实施修复。" (cause found, fix in progress)
• 04:49, monitoring: "已实施修复，正在监控结果。" (fix applied, monitoring)
• 05:04, resolved: "本次问题已解决，服务已恢复。" (resolved, service restored)

The page puts the total at 4 hours 52 minutes. Caixin reports that the web and app were showing "服务器暂时不可用" (server temporarily unavailable) from around 8:00 Beijing time, and that the chat service was fully down from 9:08. TechNode also reports the outage across chat and both API models.

DeepSeek has not said what failed. The compensation notice, reproduced by IT之家, says the company has started a full review of service stability and will remove single points of dependency. When one incident takes down a chat product and two API models together, that wording fits: something underneath was shared.

One shared dependency under three services: the chat product and both API models went down in the same incident.

What the credit covers, and what it doesn't

The terms, as reported by The Paper and IT之家:

• The credit equals what your account consumed from October 8 to October 14.
• It arrives as bonus balance (赠金), applied automatically.
• It goes to API users, the people the notice addresses.

DeepSeek's pricing page adds the detail that matters for your next invoice: "当充值余额与赠送余额同时存在时，优先扣减赠送余额。" When you have both a top-up balance and a bonus balance, the bonus balance is used first. So the credit is spent before your cash, once it lands.

The credit tracks your past spend, not your loss. If you spent a lot from October 8 to 14, you get a lot back. If you were still prototyping that week, you get a little, even if the October 15 outage hit your launch.

The credit also stops at your bill. The requests your product failed to answer, the retries that piled up and the support tickets that followed aren't in it.

The notice, as reported, doesn't say whether the credit expires. Check your balance page on the DeepSeek platform rather than assuming.

Not the first incident since September

Caixin counts 13 faults since September. Most were degraded performance on web and API, and four involved partial outages of web and API. On October 15, the status page showed uptime for July to October 2026 of 99.74% for the V4 Pro API service and 99.47% for the V4.1 Flash API service.

V4.1 Flash is new. DeepSeek announced it on September 10 and calls it "the smallest model in our new architecture family," served in the API as deepseek-flash. One newsletter connects the run of incidents to demand for the new model. DeepSeek hasn't said that, so treat it as a guess.

None of this makes DeepSeek unusually fragile. Every hosted model API has bad mornings. The lesson is the same one DeepSeek wrote into its own notice: one dependency under everything is a risk, and your app has the same problem if every LLM call goes to one provider.

Put a second provider behind your DeepSeek calls

DeepSeek's API docs say the API is compatible with the OpenAI format, at the base URL https://api.deepseek.com, and they show it working with the official OpenAI Node SDK. That makes a fallback cheap: a second client with a different base URL and model.

Fail over on the errors an outage produces, and only on those.

import OpenAI from "openai";

type Msg = OpenAI.Chat.ChatCompletionMessageParam;

const primary = new OpenAI({
  baseURL: "https://api.deepseek.com",
  apiKey: process.env.DEEPSEEK_API_KEY,
  timeout: 20_000,
  maxRetries: 1,
});

const fallback = new OpenAI({
  baseURL: process.env.FALLBACK_BASE_URL,
  apiKey: process.env.FALLBACK_API_KEY,
  timeout: 20_000,
  maxRetries: 1,
});

function shouldFailOver(err: unknown): boolean {
  if (!(err instanceof OpenAI.APIError)) return false;
  const s = err.status;
  return s === undefined || s === 429 || s >= 500;
}

export async function chat(messages: Msg[]) {
  try {
    return await primary.chat.completions.create({
      model: "deepseek-flash",
      messages,
    });
  } catch (err) {
    if (!shouldFailOver(err)) throw err;
    return fallback.chat.completions.create({
      model: process.env.FALLBACK_MODEL ?? "",
      messages,
    });
  }
}

A few choices in there are deliberate:

• timeout and maxRetries are SDK options. A short timeout and a single retry keep a dead endpoint from holding your request for minutes before the fallback gets a turn. The fallback gets the same limits, in case it is slow too.
• Connection failures and timeouts reach you as APIError subclasses with no status, so status === undefined counts as an outage. So do 429 and 5xx.
• A 400 or 401 doesn't fail over. A bad request or a bad key is your bug, and sending it to a second provider only hides it.
• The fallback is any OpenAI-compatible endpoint you already trust, set by environment variable. Cost matters less here than whether it stays up when DeepSeek doesn't.

A different model can give different answers, so if you parse structured output, run your evals against the fallback model too. And log which provider served each request, or you won't know how often you're running on the backup.

What to do this week

1. Open your DeepSeek platform balance and confirm the credit landed, and how much it is.
2. Remember the bonus balance is drawn first, so your cash balance will sit still for a while. Adjust any spend alerts that watch it.
3. Check your logs for 00:11–05:04 UTC on October 15 and count the requests that failed. That number is closer to your real cost of the outage, and the credit doesn't cover it.
4. Add a fallback like the one above, and test it by pointing the primary at a bad base URL in staging.

I haven't run this against DeepSeek's API myself. The pattern is plain SDK usage, and it should work the same for any provider that speaks the OpenAI format.

---

If this was useful

Every design in the System Design Pocket Guide: Interviews comes down to trade-offs like this one: what each dependency costs you when it fails, and what you pay to survive that. A model API is one more dependency in that list, and October 15 was a reminder to design for it going away.

If the thing calling a model API is your coding agent, I build Hermes IDE, so weigh this with that in mind. It lets you pick the agent, model and account per task, and when one agent hits its usage limit you can continue the task in another. It's free to download, source-available under BSL 1.1, runs on macOS, Windows and Linux, and is on GitHub. It isn't affiliated with Nous Research, DeepSeek or any agent vendor.