---
title: "AI Service Outages Sep–Oct 2026: OpenAI and Claude Incident Stats"
description: "110 incidents from seven official status pages, 2026-09-17 to 10-17, broken down by vendor, severity and duration, with retry, fallback and failover tactics."
url: https://cdnping.org/en/blog/ai-service-incidents-sep-oct-2026
language: en
published: 2026-10-17
category: "Service updates"
tags: ["AI outages","status pages","OpenAI","Claude","failover","API reliability"]
source: cdnping.org
license: Free to quote and summarize with a link to the url above.
---
# AI Service Outages Sep–Oct 2026: OpenAI and Claude Incident Stats

How often do AI services go down? Between September 17 and October 17, 2026, the seven official status pages that cdnping syncs logged 110 incidents. OpenAI had 25 and Anthropic (Claude) had 8, and 6 of those 8 Claude incidents were labeled major by Anthropic itself. Of the latest 40 incidents (October 9 to 16), 31 have complete timestamps, and their median duration is 146 minutes, about two and a half hours. At that rate, retries, timeouts and a fallback path in your calling code are not optional.

## Where the data comes from and how to read it

- Source: cdnping's [API status page](/en/status) syncs the official status pages of OpenAI, Anthropic, Moonshot (Kimi), Groq, Cloudflare, GitHub and Cursor every 15 minutes. The numbers here come from a data snapshot generated on 2026-10-17. Incident titles, severity levels, start times and end times are the raw fields from each vendor's status page.
- Window: the vendor totals cover 2026-09-17 to 2026-10-17. The per-incident list contains only the latest 40, spanning 2026-10-09 22:37 to 10-16 17:56 (UTC).
- Limitation: cdnping began collecting its own data on 2026-10-17. Earlier incidents were backfilled from status page history. One month of data should not be treated as a long-term reliability ranking.
- Severity levels are not comparable across vendors: none / minor / major / critical are assigned by each vendor under its own standards. For example, all 8 Moonshot incidents in this period are labeled critical, which more likely reflects its labeling habits than any conclusion that it is less stable than the others.

## Incidents by vendor and severity

| Vendor | Total incidents | critical | major | minor | none |
|---|---|---|---|---|---|
| OpenAI | 25 | 0 | 4 | 19 | 2 |
| Cursor | 25 | 0 | 5 | 20 | 0 |
| Cloudflare | 25 | 0 | 3 | 19 | 3 |
| GitHub | 16 | 5 | 1 | 10 | 0 |
| Anthropic (Claude) | 8 | 0 | 6 | 1 | 1 |
| Moonshot (Kimi) | 8 | 8 | 0 | 0 | 0 |
| Groq | 3 | 0 | 1 | 2 | 0 |
| **Total** | **110** | **13** | **20** | **71** | **6** |

*Source: official vendor status pages, synced via cdnping /status; window 2026-09-17 to 2026-10-17.*

A few observations:

1. OpenAI has many incidents, but mostly minor ones. 19 of its 25 are minor. Judging by the titles of the most recent ones, most are degradations of a single feature, product line or endpoint.
2. Claude has few incidents, but a high share of major ones. 6 of 8 are major. Fewer incidents does not mean smaller impact, so don't plan contingencies on counts alone.
3. Infrastructure fails too. Cloudflare and GitHub are not model vendors, but many AI applications depend on them for gateways, Workers, CI and code hosting. Cloudflare logged 25 incidents this month, and from the recent titles most concern a specific region's nodes or a single product.
4. Developer tools inherit upstream problems. One recent Cursor incident is titled after an upstream model vendor's errors (Elevated errors affecting Grok models), which shows that an IDE-style tool's availability depends on both itself and the model providers it calls.

## Incidents by duration

Of the 40 incidents from October 9 to 16, 7 have an end time earlier than their start time (the status page revised the start time retroactively, or the incident was logged after the fact), and 2 more are recorded as 0 minutes (marked Retroactive or missing an end time). Excluding those 9 leaves 31:

| Duration | Incidents | Share |
|---|---|---|
| Under 30 minutes | 4 | 13% |
| 30–60 minutes | 6 | 19% |
| 1–3 hours | 10 | 32% |
| 3–10 hours | 7 | 23% |
| Over 10 hours | 4 | 13% |

*Source as above; sample of 31 incidents, window 2026-10-09 to 2026-10-16 (UTC).*

The median is 146 minutes. The 4 incidents over 10 hours are, judging by their titles, long degradations of a subsystem or region. For example, Cloudflare's "Elevated Errors in China Network Colos" lasted about 7,515 minutes (about 5.2 days), and OpenAI's "Delayed Costs data in the Compliance API" lasted about 2,504 minutes. Long-tail incidents like these don't necessarily make requests fail, but they raise latency, cause errors in some regions or delay data, and they are easy to mistake for a bug in your own code.

For anyone writing retry logic, these numbers say that most incidents do not recover within seconds. Retries only absorb transient blips. A degradation that lasts an hour or two needs circuit breaking and failover.

## Representative incidents

Titles are quoted verbatim from the status pages; severity and duration come from the status page fields. Only incidents directly relevant to AI development are listed.

| Time (UTC) | Vendor | Status page title (verbatim) | Severity | Duration |
|---|---|---|---|---|
| 10-15 16:29 | OpenAI | Widespread feature degradation | major | 146 min |
| 10-14 07:05 | OpenAI | Degraded performance in Codex and ChatGPT Work | minor | 167 min |
| 10-14 17:00 | OpenAI | Delayed Costs data in the Compliance API | minor | 2,504 min |
| 10-15 07:10 | Cloudflare | Cloudflare Workers AI Issues | minor | 146 min |
| 10-15 10:47 | Cloudflare | Increased HTTP 502 Errors | minor | 591 min |
| 10-10 04:13 | Cloudflare | Elevated Errors in China Network Colos | minor | 7,515 min |
| 10-15 22:25 | Cursor | Elevated errors affecting Grok models | minor | 415 min |
| 10-13 00:22 | Cursor | Degraded performance and errors across Cursor services | minor | 165 min |
| 10-12 18:17 | Groq | Model Performance or Availability Issue | major | 18 min |
| 10-12 12:21 | GitHub | Incident with Actions, Pull Requests and Issues | minor | 474 min |

*Source: official status pages of OpenAI, Cloudflare, Cursor, Groq and GitHub, synced via cdnping.*

The latest 40 incidents contain none from Anthropic or Moonshot; all of their incidents this month happened before October 9. You can see their 30-day history on the [Anthropic status page](/en/status/anthropic) and the [Moonshot status page](/en/status/moonshot). OpenAI's is at [/en/status/openai](/en/status/openai).

## When something breaks, work out whose problem it is first

When you see an error, spend two minutes working out which layer is failing, then decide whether to wait, switch, or fix your own configuration.

### Troubleshooting order

1. Open the [Is it down?](/en/down) page, for example [/en/down/claude](/en/down/claude) or [/en/down/chatgpt](/en/down/chatgpt). It combines the official status page, a 5-minute API probe and one-click reports from other users, so you can see whether "everyone is down."
2. Check [API status](/en/status). cdnping probes each vendor's official API endpoint from the Cloudflare edge every 5 minutes. If the edge probe is healthy and yours isn't, the problem is most likely in your network or configuration.
3. Test your own path. On the [speed test](/en) page you can see the first-connection and round-trip times to each vendor's API; in [IP and environment check](/en/ip) you can confirm whether your egress IP, DNS leak status or traffic routing has changed. When you need to send a result to a coworker or paste it into a ticket, /en/ip can generate a watermarked result image, and you can choose to hide the IP address before exporting. The fingerprint is computed locally in the browser and is not uploaded.
4. Match the response code against the table below.

### Response code reference

| Symptom | Common cause | Suggested action |
|---|---|---|
| 429 | Rate limit or quota exhausted | For rate limits, read `Retry-After` and retry with backoff; if quota is exhausted, retrying is pointless, so check the account |
| 500 / 502 / 503 | Server or gateway failure | Retry a limited number of times, then switch to a backup once past the threshold |
| 529 (Anthropic API) | Service overloaded | Same as above; a good case for switching quickly |
| Connection timeout, TLS handshake failure | Network path or DNS | Check your local network first; don't rush to change providers |
| 401 / 403 | Key, permission or region restriction | Don't retry; check the key and account status, and follow the terms of service |
| 200 but odd output quality | Model-side change or degradation | Check [site changes](/en/changes) and [model monitoring](/en/models) |

## Practices to build into your code

### 1. Limited retries with backoff

Retry only retryable errors, at most three or four times, with exponentially growing intervals plus random jitter. Here is an SDK-agnostic version in Python:

```python
import random, time
import httpx

RETRYABLE = {408, 429, 500, 502, 503, 504, 529}

def call_with_retry(send, max_attempts=4, base=1.0, cap=20.0):
    for attempt in range(1, max_attempts + 1):
        try:
            resp = send()
        except (httpx.ConnectError, httpx.ReadTimeout):
            resp = None
        if resp is not None and resp.status_code < 400:
            return resp
        if resp is not None and resp.status_code not in RETRYABLE:
            resp.raise_for_status()          # fail immediately on 401/403/400 etc.
        if attempt == max_attempts:
            raise RuntimeError("retries exhausted")
        wait = min(cap, base * 2 ** (attempt - 1))
        ra = resp.headers.get("retry-after") if resp is not None else None
        if ra and ra.isdigit():              # only handle the seconds format
            wait = max(wait, float(ra))
        time.sleep(wait * random.uniform(0.5, 1.0))
```

### 2. Circuit breaking: don't let retries sink you

The median duration above is 146 minutes. During a sustained degradation, retrying every request 4 times only makes queuing and timeouts worse. A simple circuit-breaker rule:

- If a provider's failure rate over the last 60 seconds exceeds 50% and there were at least 20 requests, mark it "open" and send it no requests for 5 minutes;
- After 5 minutes, let 1–2 probe requests through, and restore the provider if they succeed.

These thresholds are examples; adjust them to your own traffic.

### 3. Degrade instead of erroring out

Not every feature needs the strongest model. Decide a degradation order ahead of time, for example:

- When the primary model is unavailable, switch to a lighter model from the same vendor;
- When the whole vendor is unavailable, switch to another vendor;
- When nothing is available, return a cached result or an explicit "please try again later" message, and put the task in a queue.

### 4. Multiple providers

In this month, none of the 7 vendors had zero incidents. Connect to only one and you absorb all of its downtime; connect to two or more and you at least have a way out when one has trouble. There are two ways to do it:

- Maintain it yourself: integrate two or more APIs at once, manage each one's keys, billing and interface differences, and compute circuit-breaker state per provider.
- Use an aggregation gateway: for example [AGI Plan](https://agiplan.dev) (AGI Plan is a commercial partner of cdnping). It is compatible with both the OpenAI and Anthropic interface formats, so tools such as Claude Code and Codex only need one endpoint changed to switch between multiple capability groups using the same quota. A gateway is itself another dependency; it publishes hourly, per-capability-group success and failure counts, which cdnping mirrors at [/en/status/agiplan](/en/status/agiplan), so you can check them before integrating. AGI Plan states clearly that it is not an officially authorized channel; some models are marked "outside China only," so refer to its [models page](https://agiplan.dev/models), and follow each vendor's terms of service and local regulations when using it.

Whichever you choose, we recommend manually pointing the primary provider's address at an unreachable one in a test environment, to confirm the failover path actually works.

## What to do next

- Bookmark [/en/status](/en/status) or a specific vendor page so it's the first place you look when something breaks.
- Subscribe to the [weekly stability report](/en/reports), generated automatically every Monday, which shows how each vendor's incidents and probe data changed over the previous week.
- If you want to run your own statistics, use cdnping's open data endpoint `/api/status` (CC BY 4.0); see the [methodology](/en/methodology) for how the data is defined.
- Audit your own calling code: Do you have timeouts? Do you distinguish retryable errors? Do you have circuit breaking? Do you have a backup path? Fix whichever of the four is missing first.