AI API outages on September 28, 2026
UTC day · measured every 5 minutes from 4 regions · method
On September 28, 2026 (UTC) our probes attributed 1 outage(s) to 1 provider(s): Gemini API (Google): 1. Providers’ own status pages opened 1 entry (TypeSafe).
This page is history. Is it down right now?
Live status, updated every 30 minutes: Gemini API (Google), TypeSafe API, baichuan API, friendli API, iflytek API, stepfun API · all AI APIs, last 72 hours
Was the Gemini API (Google) down on September 28, 2026?
Yes, measured. 1 outage(s) attributed to Google: requests to gemini-flash-lite-latest failed from up to 2 of 4 regions at once while no other provider was failing, first at 06:05 UTC, each shorter than one 5-minute probe cycle.
| UTC | What failed | Regions | Duration | Failed probes | Verdict | Error |
|---|---|---|---|---|---|---|
| 02:25–02:45 | requests to gemini-flash-lite-latest | 3 of 4: Asia (Tokyo), Europe (Germany), US (Central) | ≥20 min | 3 | shared with 1 other provider(s) — not attributed | timeout |
| 05:05–05:05 | requests to gemini-flash-lite-latest | 2 of 4: South America (São Paulo), US (Central) | <5 min | 2 | shared with 1 other provider(s) — not attributed | timeout |
| 06:05–06:05 | requests to gemini-flash-lite-latest | 2 of 4: South America (São Paulo), US (Central) | <5 min | 2 | provider outage | timeout |
| 06:45–07:05 | requests to gemini-flash-lite-latest | 4 of 4: Asia (Tokyo), Europe (Germany), South America (São Paulo), US (Central) | ≥20 min | 5 | shared with 3 other provider(s) — not attributed | timeout |
| 08:55–09:05 | requests to gemini-flash-lite-latest | 2 of 4: Asia (Tokyo), Europe (Germany) | ≥9 min | 2 | shared with 1 other provider(s) — not attributed | timeout |
| 11:45–18:25 | requests to gemini-flash-lite-latest | 4 of 4: Asia (Tokyo), Europe (Germany), South America (São Paulo), US (Central) | ≥400 min | 80 | shared with 19 other provider(s) — not attributed | http 503; timeout |
| 19:05–21:45 | requests to gemini-flash-lite-latest | 4 of 4: Asia (Tokyo), Europe (Germany), South America (São Paulo), US (Central) | ≥160 min | 31 | shared with 3 other provider(s) — not attributed | http 503; timeout |
| 22:35–22:45 | requests to gemini-flash-lite-latest | 2 of 4: Europe (Germany), South America (São Paulo) | ≥9 min | 2 | shared with 1 other provider(s) — not attributed | timeout |
Is the Gemini API (Google) down right now? Live status →
Was the TypeSafe API down on September 28, 2026?
Not attributably. 5 multi-region failure(s) of TypeSafe coincided with failures of other providers, so the cause sat above TypeSafe and is not blamed on it. TypeSafe’s own status page opened 1 entry that day (self-reported, listed below).
| UTC | What failed | Regions | Duration | Failed probes | Verdict | Error |
|---|---|---|---|---|---|---|
| 13:21–13:50 | host probes | 4 of 4: Asia (Tokyo), Europe (Germany), South America (São Paulo), US (Central) | ≥29 min | 9 | shared with 3 other provider(s) — not attributed | http 503; timeout |
| 13:35–13:35 | requests to jev-1.13.0 | 2 of 4: Europe (Germany), US (Central) | <5 min | 2 | shared with 3 other provider(s) — not attributed | http 503 |
| 14:55–14:55 | requests to jev-1.13.0 | 2 of 4: Asia (Tokyo), US (Central) | <5 min | 2 | shared with 1 other provider(s) — not attributed | timeout |
| 15:01–15:25 | host probes | 3 of 4: Asia (Tokyo), Europe (Germany), South America (São Paulo) | ≥24 min | 5 | shared with 4 other provider(s) — not attributed | timeout |
| 16:00–16:06 | host probes | 2 of 4: Europe (Germany), South America (São Paulo) | ≥6 min | 2 | shared with 2 other provider(s) — not attributed | timeout |
Self-reported on TypeSafe’s status page, not verified by our probes:
- notice Degradation in API Traffic · resolved Sep 28, 16:07 UTC
Is the TypeSafe API down right now? Live status →
Was the baichuan API down on September 28, 2026?
Not attributably. 4 multi-region failure(s) of baichuan coincided with failures of other providers, so the cause sat above baichuan and is not blamed on it.
| UTC | What failed | Regions | Duration | Failed probes | Verdict | Error |
|---|---|---|---|---|---|---|
| 00:50–01:00 | host probes | 2 of 4: Asia (Tokyo), South America (São Paulo) | ≥10 min | 2 | shared with 2 other provider(s) — not attributed | timeout |
| 07:30–07:45 | host probes | 2 of 4: Asia (Tokyo), US (Central) | ≥15 min | 2 | shared with 2 other provider(s) — not attributed | [Errno 101] Network is unreachable; timeout |
| 09:10–09:25 | host probes | 2 of 4: Asia (Tokyo), South America (São Paulo) | ≥15 min | 2 | shared with 2 other provider(s) — not attributed | [Errno 101] Network is unreachable; timeout |
| 14:00–14:05 | host probes | 2 of 4: Asia (Tokyo), South America (São Paulo) | ≥5 min | 2 | shared with 5 other provider(s) — not attributed | timeout |
Is the baichuan API down right now? Live status →
Was the friendli API down on September 28, 2026?
Not attributably. 1 multi-region failure(s) of friendli coincided with failures of other providers, so the cause sat above friendli and is not blamed on it.
| UTC | What failed | Regions | Duration | Failed probes | Verdict | Error |
|---|---|---|---|---|---|---|
| 12:55–13:00 | host probes | 3 of 4: Europe (Germany), South America (São Paulo), US (Central) | ≥5 min | 3 | shared with 5 other provider(s) — not attributed | timeout |
Is the friendli API down right now? Live status →
Was the iflytek API down on September 28, 2026?
Not attributably. 2 multi-region failure(s) of iflytek coincided with failures of other providers, so the cause sat above iflytek and is not blamed on it.
| UTC | What failed | Regions | Duration | Failed probes | Verdict | Error |
|---|---|---|---|---|---|---|
| 10:10–10:15 | host probes | 2 of 4: Asia (Tokyo), South America (São Paulo) | ≥5 min | 2 | shared with 1 other provider(s) — not attributed | [Errno 104] Connection reset by peer; timeout |
| 14:05–14:25 | host probes | 2 of 4: Asia (Tokyo), South America (São Paulo) | ≥20 min | 3 | shared with 12 other provider(s) — not attributed | timeout |
Is the iflytek API down right now? Live status →
Was the stepfun API down on September 28, 2026?
Not attributably. 1 multi-region failure(s) of stepfun coincided with failures of other providers, so the cause sat above stepfun and is not blamed on it.
| UTC | What failed | Regions | Duration | Failed probes | Verdict | Error |
|---|---|---|---|---|---|---|
| 14:05–14:20 | host probes | 2 of 4: South America (São Paulo), US (Central) | ≥15 min | 2 | shared with 11 other provider(s) — not attributed | timeout |
Is the stepfun API down right now? Live status →
Was the yi-01ai API down on September 28, 2026?
Not attributably. 3 multi-region failure(s) of yi-01ai coincided with failures of other providers, so the cause sat above yi-01ai and is not blamed on it.
| UTC | What failed | Regions | Duration | Failed probes | Verdict | Error |
|---|---|---|---|---|---|---|
| 08:00–08:10 | host probes | 2 of 4: Asia (Tokyo), US (Central) | ≥10 min | 3 | shared with 2 other provider(s) — not attributed | timeout |
| 09:15–09:15 | host probes | 2 of 4: Asia (Tokyo), South America (São Paulo) | <5 min | 2 | shared with 2 other provider(s) — not attributed | timeout |
| 14:15–14:25 | host probes | 2 of 4: South America (São Paulo), US (Central) | ≥10 min | 2 | shared with 9 other provider(s) — not attributed | [Errno 104] Connection reset by peer; timeout |
Is the yi-01ai API down right now? Live status →
102 single-region failure(s) were also recorded that day (iflytek 23, baichuan 20, yi-01ai 19, google 7, deepinfra 5, stepfun 3, sensenova 3, aleph-alpha 3, doubao 2, fireworks 2). A failure seen from one region cannot be separated from a problem on that network path, so none of them is called an outage.
How is an outage told apart from a network problem?
Each provider is probed every five minutes from 4 independent regions. A failure is attributed to the provider only when it is seen from two or more regions at once and no other provider fails in the same minutes; a failure shared with other providers has a cause above all of them and is not blamed on anyone. Durations are lower bounds: we see the first and last failed probe, not the real start and end. Status-page entries are the provider’s own words, shown next to the measurement, not instead of it.
Machine-readable: incidents.json · Licence: CC BY 4.0