The morning of October 15
I had a debugging session and a batch of documentation queued for that morning, and both of them ran through DeepSeek. That is how I ended up refreshing a status page every few minutes instead of shipping anything.
The timeline, as the status page told it
DeepSeek had a large-scale service failure on the morning of October 15. The chat service, the DeepSeek V4.1 Flash API and the V4 Pro API were all involved. Chat was fully down for a period, both APIs were partially interrupted, and performance degraded on the website and the API at the same time. File upload and search were unaffected.
The public status page recorded four moments.
- 08:11, the problem was being investigated.
- 09:06, the cause had been identified and a fix was being implemented.
- 12:49, the fix went live and the service entered monitoring.
- 13:04, the incident was marked resolved and service was restored.
Nearly four more hours passed between identifying the cause and restoring service. That gap is the part I keep coming back to. Knowing what is broken and having a working service again are two different milestones.
What DeepSeek said afterwards, and what it is paying back
After service came back, DeepSeek published an apology and compensation notice. It said a comprehensive review and remediation effort focused on service stability is underway, and that it will systematically comb through and eliminate single points of dependency.
A single point of dependency is easy to describe. When one critical link fails, every service sitting behind it goes down with it. DeepSeek has not disclosed the specific trigger of this incident, or which link failed, and a full technical explanation has not been published yet.
The compensation terms are more concrete. Each account gets the full amount of its API consumption between October 8 and October 14 back in the form of credits. The credits arrive automatically and are applied first to subsequent API calls. Spend 100 yuan over those seven days and 100 yuan in credits lands in the account, with no application needed. Developers who have used the API recently can check the usage page on the DeepSeek open platform to see whether the credit has arrived.
Why I stopped treating this as a one-off
Thirteen incidents since September 2
The status page history is longer than most people assume. There have been 13 incidents since September 2, ranging from degraded performance to partial outages, and two of them happened on October 12 alone. The availability figures for July through October look like this.
| Service | Availability, July to October |
|---|---|
| V4 Pro API | 99.74% |
| V4.1 Flash API | 99.47% |
| Chat service | 99.78% |
The same failure shape exists on my side
The official statement mentioned eliminating single points of dependency, and that is a fix on the provider side. My project has the same shape of problem, and I control that one. Every AI call in my code pointed at one channel, which meant one bad afternoon at a vendor took my work with it. The fix on my side is not a technical achievement. It is a routing decision I had put off for months.
The manual response, and where mine broke
Three things I used to do
When an outage hit, my reaction looked like this.
- Swap in another API Key.
- Edit the base URL in the code.
- Restart the service and try again.
The part that does not scale
All of it requires someone watching. Switching channels means changing configuration, and once that is done there is still the job of remembering to change it back. With several projects and several coding tools running at the same time, every one of them needs the same edit. An outage at three in the morning, or halfway through a long task, is harder to contain than a bad afternoon.
The reasonable answer is to put channel switching behind a single unified entry point, so tools and code connect to that entry point and nothing else.
Putting one local AI gateway in front of everything
Core idea, and an honest fit check
Every tool stores its model config in its own file, in its own format, with its key and base URL managed separately. When one channel breaks, each tool has to be fixed on its own.
ServBay, a one-stop AI development management tool, keeps this in one app and one local gateway. All tools go through the same local entry point, so switching a model or a channel no longer means editing each tool's config. A key is entered once per provider and works everywhere, the real key is stored encrypted on the machine, and tools only ever receive a virtual key. A problem on one channel does not cut work off, because the gateway automatically switches to a healthy backup channel when the primary one is rate-limited or down.
This fits anyone running multiple tools, multiple channels or multiple projects at the same time. Someone using one tool and one channel, where an occasional interruption does not affect the work, does not need it yet.
If the search that brought you here was about a cc-switch alternative, one distinction matters. A switcher answers which provider a tool points at. A gateway answers how traffic is routed once it arrives, which is a different job, and only the second one keeps running while nobody is watching.
One entry point, every model
Claude Code and Codex only need their base URL pointed at the gateway. After that, changing models or providers happens inside ServBay, and the tools themselves stay untouched.
The gateway converts between the Anthropic, OpenAI and Gemini API formats. That lets models from different vendors sit behind the same entry point, and local Ollama models are no exception. Adding a provider takes a provider selection and a key. There are currently native integrations with 12+ providers, including OpenAI, Anthropic, Gemini, DeepSeek, Kimi, Zhipu GLM, Qwen, Baidu Qianfan and Tencent TokenHub, plus support for anything compatible with the OpenAI API.
Connectivity tests that catch a dead backup early
Once a provider is added, two levels of testing are available. Without a key, it checks whether the endpoint is reachable. With a key, it checks whether the credentials are valid.
The value showed up for me at configuration time rather than during an outage. A backup channel that was never actually usable is worse than no backup channel, because the failure only surfaces at the worst possible moment.
Failover, with a clear boundary
The same model can be wired to several channels, for example the official DeepSeek channel plus other platforms that also serve that model. Three routing modes cover the common setups. Fixed mode always uses the same channel. Failover mode uses the first channel and, on failure, tries the backup channels in order. Balanced mode rotates requests across channels and is a VIP feature.
The boundary matters. Failover only applies between channels that can serve the same model, and different models are never mixed. The gateway does not choose a model on the caller's behalf. When a different model is needed, the tool still specifies it.
Virtual keys issued per project
Projects and downstream tools call through local virtual keys, and the upstream real key is never exposed to them. One key can be issued per project or per tool, and each one can be revoked individually. If a project's key leaks, revoking it is enough and the real key stays untouched.
One-click takeover of the CLI tools I run
ServBay supports one-click takeover of Claude Code, Codex, opencode, Crush, Qwen Code, Kimi CLI and CodeBuddy. There is no manual editing of export environment variables and no digging through .zshrc. One click in the interface and these tools' requests go through the local gateway.
Usage and cost are visible per channel in one place, so reconciling several projects no longer means opening each provider's billing page.
My setup, in three steps plus two
The three steps
- Add a provider. Each provider's real key is entered once, stored encrypted on the machine and never uploaded.
- Issue virtual keys per project or per tool.
- Point the tools' base URL at the gateway.
After that, switching a model or a provider no longer requires touching the tools.
The two extra steps for outage days
Handling an incident like the one on October 15 takes two more actions.
- Add at least two channels for the same model, and make sure one of them does not depend on DeepSeek's official service. A backup channel sitting behind the same failed vendor solves nothing.
- Choose failover as the routing mode, put the primary channel first, then run connectivity testing to confirm the backup channel is usable.
Failover is free and is not charged per token.
Questions that show up in every outage thread
DeepSeek will not open and reports that the server is busy. What now?
Check the official status page first to confirm whether it is a provider-side outage. If it is, switching temporarily to another channel or another model gets work moving again. For anything long term, backup channels are better set up in advance than improvised at the moment of failure.
How can a current DeepSeek outage be confirmed?
The official status page reports the chat service, the V4 Pro API, the V4.1 Flash API, the file upload service and the search service separately, and records the handling progress of each incident.
Will failover switch to a different model on its own?
No. Failover happens between channels that can serve the same model, and different models are never mixed. The model is specified by the caller in each request, and the gateway only routes the request to a channel that can serve it.
Is it safe to put an API Key into the gateway?
The real key is stored encrypted on the local machine and is never uploaded. Tools and projects use a virtual key, which can be revoked at any time.
Does failover cost anything?
No. The gateway endpoint, virtual keys, usage and cost statistics, automatic failover and local encryption are all free features. Team features such as balanced routing and budget limits are part of VIP.
Wrapping up
Where to get it
AI Gateway is released with ServBay 1.33.0. Existing users can upgrade by clicking Check for Updates in ServBay's Settings. New users can download it from www.servbay.com/download.
This outage has been resolved and compensation is being distributed. Nobody can know in advance when the next anomaly arrives. Connecting multiple channels for the same model to the gateway ahead of time means a failure on one side does not bring the project to a halt.
Top comments (0)