# ChatGPT, Codex and GitHub all stumbled this week. A fallback plan so your team keeps shipping

> Gigasonet blog. By Kirtan Patel, 5 Nov 2026. Canonical: https://www.gigasonet.com/blog/ai-coding-tools-outage-fallback-plan

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.

## In 30 seconds
- Between 25 October and 5 November, the OpenAI, Anthropic and GitHub status pages logged 27 incidents between them. GitHub alone had 14, two of them critical.
- On 4 November OpenAI reported elevated error rates across paid ChatGPT plans, and GitHub had three major incidents hitting pull requests, Git operations, Actions and Pages.
- A paid ChatGPT Pro user reported that ChatGPT Work was unusable for more than 48 hours from 1 to 4 November. That is one user's report, not an official post-mortem.
- The fix is not picking a more reliable vendor. It is two providers behind one interface, timeouts and retries, a circuit breaker, status alerts and a manual release path.

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](https://www.githubstatus.com/incidents/smtdswd1h2w4), then [Actions and Pages](https://www.githubstatus.com/incidents/xr3myzj7ms51), then [Actions again](https://www.githubstatus.com/incidents/h02n9572mx9y). Copilot Mission Control also had elevated task errors that morning.
- **OpenAI, 3 November:** [file upload errors in ChatGPT](https://status.openai.com/incidents/01M6FDZ89W4PKDS19K496J307G) for almost five hours.
- **OpenAI, 4 November:** [elevated error rates across paid ChatGPT plans](https://status.openai.com/incidents/01M6MBCX427A7113A3T4FJ1N6Y), 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](https://github.com/openai/codex/issues/59428) 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.

```ts
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](/services/saas-development) and [websites](/services/website-development) 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](/blog/ai-model-releases-october-2026) 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.

## FAQ

### Was Codex down in November 2026?

OpenAI's status page shows ChatGPT incidents on 3 and 4 November, including elevated error rates across paid plans on 4 November. Separately, a ChatGPT Pro user reported that ChatGPT Work was unusable for more than 48 hours from 1 to 4 November. OpenAI has not published a post-mortem for that report.

### How do I know if ChatGPT or Claude is down?

Check the official status pages at status.openai.com and status.claude.com, and GitHub's at githubstatus.com. Most status pages let you subscribe by email, webhook or RSS so outages reach your team chat automatically.

### What is an LLM fallback?

It is code that sends a request to a backup AI provider when the primary one fails or times out. Because many providers offer OpenAI-compatible APIs, the backup can often use the same request format with a different URL, key and model name.

### Should I retry every failed AI request?

No. Retry rate limits (HTTP 429) and server errors (5xx) with exponential backoff and a little random delay. Do not retry bad requests (4xx other than 429), because they will fail the same way again.

## Sources

- [Elevated error rates across paid ChatGPT plans, OpenAI status](https://status.openai.com/incidents/01M6MBCX427A7113A3T4FJ1N6Y)
- [File upload errors in ChatGPT, OpenAI status](https://status.openai.com/incidents/01M6FDZ89W4PKDS19K496J307G)
- [Incident with Pull Requests, Git Operations and Issues, GitHub status](https://www.githubstatus.com/incidents/smtdswd1h2w4)
- [Incident with Actions and Pages, GitHub status](https://www.githubstatus.com/incidents/xr3myzj7ms51)
- [Incident with Actions, GitHub status](https://www.githubstatus.com/incidents/h02n9572mx9y)
- [Elevated errors for Claude Sonnet 5.5, Anthropic status](https://status.claude.com/incidents/lqhknfdjrcst)
- [ChatGPT Work unavailable for more than 48 hours, user report on the openai/codex repository](https://github.com/openai/codex/issues/59428)