ChatGPT, Codex and GitHub all stumbled this week. A fallback plan so your team keeps shipping
Three status pages logged 27 incidents in 12 days, and one ChatGPT Pro user lost Work access for two days. Here is the data, and the five-part fallback plan we use so one AI outage never stops a release.
It is 11 in the morning, the release is due at 4, and the coding agent has stopped answering. You refresh. You switch browsers. You check X to see whether it is just you.
It was not just you this week. We pulled the incident feeds from three status pages that most development teams depend on. Here is what happened, why it hurts more than it used to, whether any vendor has solved it, and the fallback plan we run so an outage costs us minutes instead of a day.
What happened: 27 incidents in 12 days
Status pages publish their incident history as data. We counted every incident each page logged between 25 October and the morning of 5 November:
| Status page | Incidents | Most serious |
|---|---|---|
| GitHub | 14 | 2 critical, 4 major |
| Anthropic (Claude) | 6 | 4 major |
| OpenAI | 7 | 6 minor |
The worst stretch was 3 and 4 November:
- GitHub, 4 November: three major incidents in one day, covering pull requests, Git operations and issues, then Actions and Pages, then Actions again. Copilot Mission Control also had elevated task errors that morning.
- OpenAI, 3 November: file upload errors in ChatGPT for almost five hours.
- OpenAI, 4 November: elevated error rates across paid ChatGPT plans, marked resolved just under two hours later.
- Anthropic, late October: four major incidents with elevated errors on Claude Sonnet 5.5 and Fable 5.1, each lasting under two hours.
Then there is the part status pages do not show. A paid ChatGPT Pro user filed a detailed report saying ChatGPT Work was unusable across devices for more than 48 hours, from 1 to 4 November, with scheduled runs failing too. Access came back on 4 November, and the user stresses the root cause is still unknown. Treat it as one account's experience, but it matches what many developers described that week.
The pain point: one vendor is now a single point of failure
A year ago an AI outage meant you wrote the function yourself. Now agents run the long tasks, review the pull requests and trigger the deploys. When the agent stops, the whole pipeline stops with it, and a long run that fails halfway can burn usage quota on work that never finished.
The other half of the problem is where the work lives. If the plan, the half-written branch and the context are all inside one vendor's chat, an outage takes your progress hostage too.
Fixed or not?
No, and it will not be. Every vendor on that list is large, well funded and still logged incidents. Reliability will improve, but the useful question is not "which provider never goes down". It is "what does my team do in the first five minutes when one does".
The fallback plan we use
1. Put two providers behind one interface
Most model vendors now offer an OpenAI-compatible API, so switching can be a configuration change rather than a rewrite. Pick a primary and a backup from different companies, and test the backup on your real prompts every week so it is not a surprise on outage day.
type Provider = { name: string; url: string; key: string; model: string };
const retryable = (status: number) => status === 429 || status >= 500;
export async function complete(prompt: string, providers: Provider[]) {
for (const p of providers) {
for (let attempt = 0; attempt < 3; attempt++) {
try {
const res = await fetch(`${p.url}/chat/completions`, {
method: "POST",
headers: { "content-type": "application/json", authorization: `Bearer ${p.key}` },
body: JSON.stringify({ model: p.model, messages: [{ role: "user", content: prompt }] }),
signal: AbortSignal.timeout(30_000),
});
if (res.ok) return { provider: p.name, data: await res.json() };
if (!retryable(res.status)) break;
} catch {}
await new Promise((r) => setTimeout(r, 2 ** attempt * 500 + Math.random() * 250));
}
}
throw new Error("All providers failed");
}
Three details matter more than the code. Set a timeout, because a hung request is worse than a failed one. Retry only on 429 and 5xx, because retrying a bad request just repeats the error. Add jitter, so a thousand clients do not retry at the same millisecond.
2. Add a circuit breaker
If the primary fails five times in a minute, stop sending it traffic for ten minutes and go straight to the backup. That keeps users from waiting through three timeouts on every request while a vendor is down.
3. Get the alert before your users do
The status pages we used for this post publish their incidents as JSON, and most offer email, webhook or RSS subscriptions. Pipe the providers you depend on into your team chat. Knowing in minute one is the difference between switching providers and debugging your own code for an hour.
4. Keep the work in Git, not in the chat
Ask agents to commit small, working steps to a branch. If the session dies, the progress survives, and any other tool or person can pick it up. A plan that only exists in a chat window is a plan you can lose.
5. Keep a manual release path
GitHub Actions had three major incidents in one day. If your only way to deploy is a workflow, an Actions outage blocks a release even when your code is ready. Write down, and test once a month, how to deploy from a laptop with your host's command-line tool.
The result
None of this is exotic. It is the same redundancy teams already use for payments and email, applied to a dependency that became critical very quickly. The cost is a backup API key, a short wrapper and a page of runbook. The saving is every afternoon an outage would otherwise have eaten.
We build this kind of resilience into the SaaS products and websites we ship, because AI features that fail loudly lose user trust fast. If you are choosing which models to pair as primary and backup, our October model roundup has a table of which model fits which job.
Every provider will go down again. The only choice is whether your team finds out from a status alert or from a missed deadline.
Sources
- Elevated error rates across paid ChatGPT plans, OpenAI status
- File upload errors in ChatGPT, OpenAI status
- Incident with Pull Requests, Git Operations and Issues, GitHub status
- Incident with Actions and Pages, GitHub status
- Incident with Actions, GitHub status
- Elevated errors for Claude Sonnet 5.5, Anthropic status
- ChatGPT Work unavailable for more than 48 hours, user report on the openai/codex repository