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

Multi-region failures by provider, last 72 hoursSep 6Sep 7Sep 8nowgoogle: Sep 8, 11:57 – 12:00 UTC · 2 of 4 regions · at least 2 minutes · provider outage — nobody else was failingyi-01ai: Sep 8, 09:15 – 09:20 UTC · 2 of 4 regions · at least 5 minutes · 1 other provider(s) failed in the same minutes — not attributedyi-01ai: Sep 7, 02:30 – 02:40 UTC · 2 of 4 regions · at least 10 minutes · 1 other provider(s) failed in the same minutes — not attributedyi-01ai: Sep 6, 12:55 – 13:00 UTC · 2 of 4 regions · at least 5 minutes · provider outage — nobody else was failingfriendli: Sep 8, 08:35 – 08:42 UTC · 3 of 4 regions · at least 8 minutes · provider outage — nobody else was failingaleph-alpha: Sep 7, 11:50 – 11:57 UTC · 4 of 4 regions · at least 8 minutes · 1 other provider(s) failed in the same minutes — not attributedsiliconflow: Sep 7, 10:12 – 11:35 UTC · 4 of 4 regions · at least 82 minutes · 4 other provider(s) failed in the same minutes — not attributed
googleyi-01aifriendlialeph-alphasiliconflow

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)ProviderRegions hitWhichDurationFailed probesDid they say so?
2026-09-08 11:57google
requests to gemini-flash-lite-latest
2 of 4Europe (Germany), South America (São Paulo)≥2 min2No machine-readable status page
2026-09-08 08:35friendli3 of 4Asia (Tokyo), Europe (Germany), South America (São Paulo)≥8 min3No machine-readable status page
2026-09-06 12:55yi-01ai2 of 4Asia (Tokyo), South America (São Paulo)≥5 min2No 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)ProviderRegions hitWhichDurationFailed probesDid they say so?
2026-09-08 09:15yi-01ai2 of 4Asia (Tokyo), South America (São Paulo)≥5 min2No machine-readable status page
2026-09-07 11:50aleph-alpha4 of 4Asia (Tokyo), Europe (Germany), South America (São Paulo), US (Central)≥8 min4No machine-readable status page
2026-09-07 10:12siliconflow4 of 4Asia (Tokyo), Europe (Germany), South America (São Paulo), US (Central)≥82 min68No machine-readable status page
2026-09-07 02:30yi-01ai2 of 4South America (São Paulo), US (Central)≥10 min2No 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)ProviderRegions hitWhichDurationFailed probesDid they say so?
2026-09-08 15:15yi-01ai1 of 4Asia (Tokyo)<5 min1No machine-readable status page
2026-09-08 15:00google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 14:30yi-01ai1 of 4Asia (Tokyo)≥30 min5No machine-readable status page
2026-09-08 14:00yi-01ai1 of 4Asia (Tokyo)<5 min1No machine-readable status page
2026-09-08 13:00yi-01ai1 of 4Asia (Tokyo)≥10 min2No machine-readable status page
2026-09-08 12:20yi-01ai1 of 4Asia (Tokyo)<5 min1No machine-readable status page
2026-09-08 11:40google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 11:25yi-01ai1 of 4Asia (Tokyo)<5 min1No machine-readable status page
2026-09-08 10:47hunyuan1 of 4Europe (Germany)<5 min1No machine-readable status page
2026-09-08 09:45sensenova1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 09:45yi-01ai1 of 4Asia (Tokyo)<5 min1No machine-readable status page
2026-09-08 09:25doubao1 of 4South America (São Paulo)≥20 min3No machine-readable status page
2026-09-08 09:25iflytek1 of 4South America (São Paulo)≥15 min3No machine-readable status page
2026-09-08 09:25stepfun1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 09:25baichuan1 of 4South America (São Paulo)≥10 min2No machine-readable status page
2026-09-08 09:25sensenova1 of 4South America (São Paulo)≥5 min2No machine-readable status page
2026-09-08 09:20google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 09:00google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 08:25yi-01ai1 of 4Asia (Tokyo)<5 min1No machine-readable status page
2026-09-08 07:45reka1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 07:40yi-01ai1 of 4Asia (Tokyo)≥10 min2No machine-readable status page
2026-09-08 07:40google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 07:20google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 07:05yi-01ai1 of 4Asia (Tokyo)<5 min1No machine-readable status page
2026-09-08 07:00google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 06:45doubao1 of 4US (Central)<5 min1No machine-readable status page
2026-09-08 06:35yi-01ai1 of 4Asia (Tokyo)<5 min1No machine-readable status page
2026-09-08 06:00google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 05:40google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 05:20yi-01ai1 of 4Asia (Tokyo)<5 min1No machine-readable status page
2026-09-08 05:00google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 04:35yi-01ai1 of 4Asia (Tokyo)≥15 min2No machine-readable status page
2026-09-08 03:40google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 03:30yi-01ai1 of 4Asia (Tokyo)<5 min1No machine-readable status page
2026-09-08 03:20google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 03:02reka1 of 4Europe (Germany)<5 min1No machine-readable status page
2026-09-08 03:00google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 02:40google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 02:00google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No machine-readable status page
2026-09-08 01:20google
requests to gemini-flash-lite-latest
1 of 4South America (São Paulo)<5 min1No 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.

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