AI API incident history — OpenAI, Anthropic, Google and 40+ APIs, measured from 4 regions
In the last 72 hours 3 outage(s) could be attributed to a provider with confidence. Most recent: google failed from 2 of 4 regions at once on 2026-09-08 11:57 UTC, for at least 2 minutes, while no other provider was failing.
Independent third-party outage log for AI inference APIs, built from probes run directly against each provider’s endpoint rather than from status-page polling. Observation started 2026-07-23 (47 days so far); the raw series is retained for 90 days, and the incident window below is kept deliberately shorter than that — see the last section for why.
provider outage: 2+ regions, nobody else failingmulti-region failure shared with other providers — not attributed
Every multi-region failure of the last 72 hours on one axis, a row per provider; hover a block for the details. Single-region failures are left off the timeline and listed at the bottom of this page.
How do you know it was the provider and not my network?
Every provider is probed from 4 independent regions (Asia (Tokyo), Europe (Germany), South America (São Paulo), US (Central)) every five minutes, and all 45 of them are probed on the same schedule. Two questions follow from that, and an incident has to survive both.
Did it fail from more than one place? If a request fails from one region while the others succeed, the likely cause is the path between that region and the provider — a peering problem, a route change, one bad edge node. We do not call that an outage.
Was it the only thing failing? If several unrelated APIs stop answering in the same few
minutes, the shared cause sits above all of them: a transit route, a CDN both sit behind, or our own probes.
Blaming one provider for that would be guessing. Those events are listed separately below and attributed to
nobody. What is left — failing from several regions at once, alone — is the provider, and when its
own host answers 5xx rather than going silent, the provider has said so itself. Neither a status
page nor a crowd-reporting site can make this distinction: one sees only what the provider admits, the other
only what users happen to report.
Which AI APIs had confirmed outages in the last 72 hours?
| Started (UTC) | Provider | Regions hit | Which | Duration | Failed probes | Did they say so? |
|---|---|---|---|---|---|---|
| 2026-09-08 11:57 | google requests to gemini-flash-lite-latest | 2 of 4 | Europe (Germany), South America (São Paulo) | ≥2 min | 2 | No machine-readable status page |
| 2026-09-08 08:35 | friendli | 3 of 4 | Asia (Tokyo), Europe (Germany), South America (São Paulo) | ≥8 min | 3 | No machine-readable status page |
| 2026-09-06 12:55 | yi-01ai | 2 of 4 | Asia (Tokyo), South America (São Paulo) | ≥5 min | 2 | No machine-readable status page |
Did the provider admit it?
The last column checks each failure against the provider’s own status page. Only 10 of the 45 providers tracked here publish a machine-readable status feed at all; for the rest there is nothing to check against, which is itself worth knowing before you plan around one.
Where a feed exists, both outcomes are informative. When it carries a matching entry, two
independent records agree and the timing shows which noticed first. When it carries none, we recorded
a failure their page does not mention — and that is not an accusation. Status
pages have thresholds, and a short burst of 5xx can sit legitimately below one. We report
the discrepancy; explaining it is the provider’s to do.
Which failures could not be attributed to anyone?
These hit several regions, but other providers were failing in the same minutes, so a shared upstream cause is at least as likely as a coincidence of separate outages. They are published because omitting them would flatter the data, and left unattributed because that is what the evidence supports.
| Started (UTC) | Provider | Regions hit | Which | Duration | Failed probes | Did they say so? |
|---|---|---|---|---|---|---|
| 2026-09-08 09:15 | yi-01ai | 2 of 4 | Asia (Tokyo), South America (São Paulo) | ≥5 min | 2 | No machine-readable status page |
| 2026-09-07 11:50 | aleph-alpha | 4 of 4 | Asia (Tokyo), Europe (Germany), South America (São Paulo), US (Central) | ≥8 min | 4 | No machine-readable status page |
| 2026-09-07 10:12 | siliconflow | 4 of 4 | Asia (Tokyo), Europe (Germany), South America (São Paulo), US (Central) | ≥82 min | 68 | No machine-readable status page |
| 2026-09-07 02:30 | yi-01ai | 2 of 4 | South America (São Paulo), US (Central) | ≥10 min | 2 | No machine-readable status page |
What isolated failures were recorded?
These failed from a single region only. They are published because hiding them would misrepresent the data, but they are not evidence that the provider was down.
| Started (UTC) | Provider | Regions hit | Which | Duration | Failed probes | Did they say so? |
|---|---|---|---|---|---|---|
| 2026-09-08 15:15 | yi-01ai | 1 of 4 | Asia (Tokyo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 15:00 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 14:30 | yi-01ai | 1 of 4 | Asia (Tokyo) | ≥30 min | 5 | No machine-readable status page |
| 2026-09-08 14:00 | yi-01ai | 1 of 4 | Asia (Tokyo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 13:00 | yi-01ai | 1 of 4 | Asia (Tokyo) | ≥10 min | 2 | No machine-readable status page |
| 2026-09-08 12:20 | yi-01ai | 1 of 4 | Asia (Tokyo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 11:40 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 11:25 | yi-01ai | 1 of 4 | Asia (Tokyo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 10:47 | hunyuan | 1 of 4 | Europe (Germany) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 09:45 | sensenova | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 09:45 | yi-01ai | 1 of 4 | Asia (Tokyo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 09:25 | doubao | 1 of 4 | South America (São Paulo) | ≥20 min | 3 | No machine-readable status page |
| 2026-09-08 09:25 | iflytek | 1 of 4 | South America (São Paulo) | ≥15 min | 3 | No machine-readable status page |
| 2026-09-08 09:25 | stepfun | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 09:25 | baichuan | 1 of 4 | South America (São Paulo) | ≥10 min | 2 | No machine-readable status page |
| 2026-09-08 09:25 | sensenova | 1 of 4 | South America (São Paulo) | ≥5 min | 2 | No machine-readable status page |
| 2026-09-08 09:20 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 09:00 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 08:25 | yi-01ai | 1 of 4 | Asia (Tokyo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 07:45 | reka | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 07:40 | yi-01ai | 1 of 4 | Asia (Tokyo) | ≥10 min | 2 | No machine-readable status page |
| 2026-09-08 07:40 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 07:20 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 07:05 | yi-01ai | 1 of 4 | Asia (Tokyo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 07:00 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 06:45 | doubao | 1 of 4 | US (Central) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 06:35 | yi-01ai | 1 of 4 | Asia (Tokyo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 06:00 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 05:40 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 05:20 | yi-01ai | 1 of 4 | Asia (Tokyo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 05:00 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 04:35 | yi-01ai | 1 of 4 | Asia (Tokyo) | ≥15 min | 2 | No machine-readable status page |
| 2026-09-08 03:40 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 03:30 | yi-01ai | 1 of 4 | Asia (Tokyo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 03:20 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 03:02 | reka | 1 of 4 | Europe (Germany) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 03:00 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 02:40 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 02:00 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
| 2026-09-08 01:20 | google requests to gemini-flash-lite-latest | 1 of 4 | South America (São Paulo) | <5 min | 1 | No machine-readable status page |
What did the providers’ own status pages report?
Every entry that the 10 providers with a machine-readable status feed opened in the same 72-hour window — self-reported, not verified by our probes, and shown so the two records can be read side by side. Most of these concern specific models or products: an unauthenticated probe of the API host cannot see them, and that is the gap between “the host answers” and “my requests succeed”. Feeds checked Sep 8, 15:17 UTC.
- openai · minor File uploads are delayed or failing · ongoing
- openai · minor Elevated errors for image generation · ongoing
What counts as a failure here?
A probe fails when the connection times out, is refused, or the API host answers with a 5xx status. An authentication error does not count: the probes are unauthenticated by design, so a 401 or 403 means the endpoint answered correctly and is recorded as up. Latency alone — even very high latency — is not recorded as an incident; it appears in the p95 figures instead.
Why is this window only 72 hours?
Because that is how much can be stated precisely. The underlying series is retained for 90 days and a longer view will be published once it covers enough time to distinguish a pattern from an accident. Extending the window before then would turn two coincidences into a trend, which is the opposite of the point.
Want to hear about the next one instead of reading about it here? Outage and deprecation alerts — the same measured record, delivered.
Method and limitations: methodology · Machine-readable: incidents.json · Licence: CC BY 4.0