AI API reliability 2026: what providers declare, and what they later edit
1,510 incidents from 11 AI API providers' own status pages, archived with a SHA-256, put on one taxonomy, and compared week to week so edits to the record are visible. Declared by the providers, not measured by us; captured 28 October 2026 and re-captured weekly.
In this article
What the ledger holds
1,510 incidents across 11 providers, normalised so a chat model, an embeddings endpoint and a console login are separate categories everywhere.
Every incident 11 AI providers list on their public status pages, as of 28 October 2026, back to 12 February 2021 for the deepest provider.
The whole published history was read. These cover the full 90 day window and more.
Their feeds hold only the newest incidents. Our weekly captures extend the covered window, and a window we do not cover yet is shown as unknown, not zero.
Incidents whose record changed after we first saw them resolved. This is the first edition, so it is zero by construction; it fills from the next weekly capture.
The last 90 days, as declared
Minutes in which at least one API component of the provider had a declared impact, counted once even when incidents overlap, and how much of that was a partial or full outage. Providers with no 90 day coverage yet are shown as unknown.
API impact means any component in the API surface categories (inference, embeddings, audio and voice, image and video, batch and fine-tuning, tools and files). Console, login and consumer apps are counted separately in data.json.
| Provider | History from | Incidents, 90 days | Median length | 90th percentile | API impact, minutes | of which outage |
|---|---|---|---|---|---|---|
| OpenAI | 2021-02-12 | 84 | 100 min | 9.6 h | 12,397 | 80 |
| ElevenLabs | 2024-05-17 | 23 | 2.2 h | 11 h | 5,742 | 1,425 |
| Fireworks AI | 2026-06-08 | 141 | 14 min | 118 min | 5,251 | 263 |
| Perplexity | 2024-07-30 | 8 | 57 min | 3.5 h | 485 | 179 |
| Groq | 2024-03-25 | 5 | 2.0 h | 6.1 h | 405 | 18 |
| Cerebras | 2025-01-11 | 2 | 5.0 h | 5.0 h | 298 | 298 |
| Cohere | 2024-02-16 | 2 | 4.1 h | 4.1 h | 246 | 0 |
| Stability AI | 2025-05-27 | 1 | 82 min | 82 min | 82 | 82 |
| Google Cloud (Vertex AI and Gemini) | 2026-02-27 | 0 | n/a | n/a | 0 | 0 |
| Anthropic | 2026-08-04 | 90 day window not covered yet (the ledger reaches back 84 days). Shown as unknown. | ||||
| Mistral | 2026-08-26 | 90 day window not covered yet (the ledger reaches back 62 days). Shown as unknown. | ||||
What providers promise, and what they declared
Some providers post an uptime commitment for their enterprise or priority tiers. We read each posted page on 2026-10-28 and set the stated target beside the minutes of declared partial or full outage the same provider listed on its status page, month by month. A 99.9% monthly target allows about 43 minutes of downtime in a 30 day month.
| Provider | What the posted page says | Credits and claims |
|---|---|---|
| Mistral source page read 2026-10-28 | Service Level Objective (the provider's term), with service credits. Enterprise customers with an agreement; products AI Studio and Vibe, for the part deployed on Mistral infrastructure. Uptime target: Basic 99.5%, Standard 99.9%, Premium 99.9%. Downtime: Server-side downtime, counting only downtime periods of five minutes or more; Monthly Uptime Percentage is total minutes in the month minus those minutes, divided by total minutes. | Basic: 2% of Monthly Fees at 99.4% to 95%, 5% below 95%. Standard: 2% at 99.8% to 99.5%, 5% at 99.4% to 95%, 10% below 95%. Premium: 5% at 99.8% to 99.5%, 10% at 99.4% to 95%, 20% below 95%. Total credits in a month capped at 25% of the amount owed for the affected product. Customer must email support-ent@mistral.ai within 30 days of the end of the calendar month, with the date and time of the failure; otherwise the right to a credit is forfeited. Credits are the sole and exclusive remedy and are applied within 60 days of the request (or reimbursed within 90 days of the end of the month if no further invoice). |
| OpenAI source page read 2026-10-28 | Uptime SLA and latency SLA (the provider's words) on Scale Tier. Enterprise customers who buy Scale Tier token units (minimum 30 days each) for models released before GPT-5.6; the page points GPT-5.6 and later to Reserved Tier, which was not read. Uptime target: Scale Tier, every model listed 99.9%. | Amount not stated on this page. Where both the latency SLA and the uptime SLA are violated, the customer is credited the greater of the two SLA amounts for the calendar month of the token unit purchase. |
| Groq source page read 2026-10-28 | Availability SLA and latency guarantee on the Performance tier. Enterprise plans only; models openai/gpt-oss-120b, openai/gpt-oss-20b, llama-3.3-70b-versatile; uncached context under 8,192 tokens. Uptime target: Performance 99.9%. The services agreement overview says service level agreements are among the URL Terms; no SLA text for self-serve use was found on the pages read. | not stated on the posted pages (offline agreement) |
| Anthropic source page read 2026-10-28 | No uptime commitment on the page read. Commercial Terms of Service. The whole page was searched for uptime, service level, SLA, service credit and availability. The only related wording is the disclaimer that the services and outputs are provided without warranty that use will be uninterrupted. Other documents (for example an enterprise order form) were not read, so this is not a statement that no SLA exists anywhere. | no service credits stated on this page |
Not read, so no terms are entered (that is not the same as having no SLA): Google Cloud, Cohere, Perplexity, Fireworks AI, Cerebras, Stability AI, ElevenLabs. Google Cloud's Vertex AI SLA page could not be read with the tools used here.
| Provider (target) | Month | Declared outage, minutes | Downtime budget, minutes | Declared outage against the target |
|---|---|---|---|---|
| Mistral (99.9% and 99.5%) | Apr 2026 | ledger does not cover this month yet (unknown) | ||
| May 2026 | ledger does not cover this month yet (unknown) | |||
| Jun 2026 | ledger does not cover this month yet (unknown) | |||
| Jul 2026 | ledger does not cover this month yet (unknown) | |||
| Aug 2026 | ledger does not cover this month yet (unknown) | |||
| Sep 2026 | 609 | 43.2 / 216 | over 99.9%; over 99.5% | |
| OpenAI (99.9%) | Apr 2026 | 396 | 43.2 | over 99.9% |
| May 2026 | 35 | 44.6 | within 99.9% | |
| Jun 2026 | 151 | 43.2 | over 99.9% | |
| Jul 2026 | 1022 | 44.6 | over 99.9% | |
| Aug 2026 | 0 | 44.6 | within 99.9% | |
| Sep 2026 | 47 | 43.2 | over 99.9% | |
| Groq (99.9%) | Apr 2026 | 0 | 43.2 | within 99.9% |
| May 2026 | 0 | 44.6 | within 99.9% | |
| Jun 2026 | 0 | 43.2 | within 99.9% | |
| Jul 2026 | 0 | 44.6 | within 99.9% | |
| Aug 2026 | 0 | 44.6 | within 99.9% | |
| Sep 2026 | 0 | 43.2 | within 99.9% | |
Declared against observed: this week's probe
At the weekly session we send a fixed burst of authenticated, zero-token requests (the models list) to each provider we hold a key for, from one machine, and set the result beside what the provider's own status page declared over the same minutes. This is a snapshot of the front door, not model inference and not uptime. Burst: 2026-10-28 08:20 to 2026-10-28 08:24 UTC.
| Provider | Calls that succeeded | Median | 95th percentile | Status page declared an API incident during the burst |
|---|---|---|---|---|
| OpenAI | 12 of 12 | 978 ms | 1377 ms | No |
Not probed this week (no usable API key on the machine that ran the burst: either none was present, or the key was rejected with an authentication error, which says nothing about reliability; absence is not a clean result): Anthropic, Google Cloud, Mistral, Groq, Cohere, Perplexity, Fireworks AI, Cerebras, Stability AI, ElevenLabs. One machine, one window, one location. A burst can miss an outage; it can also catch a problem the provider never declared, and each edition that happens is the evidence this layer exists for.
The revision ledger
Status pages are edited after the fact. Each weekly capture is archived byte for byte, with a SHA-256, and compared with the one before, so the ledger can list every incident whose published record changed after we first saw it: 0 so far, because this is the first edition. From the next capture the rows appear in revisions.json, each with the value before and after. A listed change is a fact about the record, not an accusation: providers correct typos, merge duplicates and fix timestamps.
The files
| File and hash | What it holds | Size |
|---|---|---|
data.jsonsha256 7db111897ed5 | Per-provider summary, coverage windows, method, limits and the taxonomy rules | 36 KB |
incidents.jsonsha256 b47a36fa575d | The ledger: every incident with its components, declared intervals and the observations that changed | 2.6 MB |
incidents.csvsha256 fe40236aa0a7 | One flat row per incident for spreadsheets | 415 KB |
revisions.jsonsha256 011bfe808506 | Incidents that changed or stopped being listed after we first recorded them | 360 B |
sla.jsonsha256 8b564b6242c8 | SLA terms as the providers post them, with source page and read date | 7.1 KB |
EVIDENCE-MANIFEST.jsonsha256 a9b1c4ab23d6 | URL, read time and SHA-256 of every archived raw status-page response | 8.1 KB |
Raw copies of every status-page response are kept in our evidence archive with the hashes above; the manifest lists each URL and read time.
How to cite it
Couey, V. W. (2026). AI API reliability ledger 2026: what AI providers declare on their own status pages. Nesyona. https://nesyona.com/research/ai-api-reliability-2026/ (captured 28 October 2026). https://doi.org/10.5281/zenodo.23724799. To cite every version: https://doi.org/10.5281/zenodo.23724798.
Cite the capture date and the file hash for a specific figure. The ledger is rebuilt weekly, so the date and hash identify the edition.
How it is built, and what it does not cover
- The probe layer (see providers[].probe) is one burst from one machine in one window: round-trip time and HTTP outcome of a zero-token, authenticated models-list request. It tests the gateway and authentication, not model inference, and it is never uptime. A provider with no probe was not probed; that is not a clean result.
- Planned maintenance (status "under maintenance" on incident.io pages) is not counted as impact; it is reported separately as plannedMaintenanceMinutesApiSurface.
- Promised against declared (slaVsDeclared) is indicative: each provider defines downtime its own way, the SLA pages posted are summaries of enterprise terms, and a declared partial outage is not the same as the contractual downtime. It is not a credit claim.
- Declared, not measured: a provider can have degraded service it never posted, and can post incidents that affected few customers. This ledger cannot see either.
- Impact labels differ by platform. incident.io pages give a per-component status (degraded, partial outage, full outage). Statuspage and Google give one incident-level label that is mapped to the same three values, so cross-provider severity comparison is approximate.
- Windows the ledger does not yet cover are null (unknown). A shorter history is not a better record.
- Components are mapped to the taxonomy by keyword; the share that fell into "other" is reported per window. Providers split and name components differently, so the category totals are comparable in kind, not exact.
- Not covered: providers with no machine-readable status history (for example the Gemini API in AI Studio, xAI, DeepSeek). They are omitted, not scored as clean.
Coverage by provider.
- OpenAI: incident.io component-impact feed (deep history); history from 2021-02-12.
- Anthropic: Atlassian Statuspage incidents feed (newest 50, accrues weekly); history from 2026-08-04.
- Google Cloud (Vertex AI and Gemini): Google Cloud status feed (filtered); history from 2026-02-27.
- Mistral: Atlassian Statuspage incidents feed (newest 50, accrues weekly); history from 2026-08-26.
- Groq: incident.io component-impact feed (deep history); history from 2024-03-25.
- Cohere: incident.io component-impact feed (deep history); history from 2024-02-16.
- Perplexity: incident.io component-impact feed (deep history); history from 2024-07-30.
- Fireworks AI: incident.io component-impact feed (deep history); history from 2026-06-08.
- Cerebras: Atlassian Statuspage incidents feed (newest 50, accrues weekly); history from 2025-01-11.
- Stability AI: incident.io component-impact feed (deep history); history from 2025-05-27.
- ElevenLabs: incident.io component-impact feed (deep history); history from 2024-05-17.
No provider was asked to comment before publication. A provider or reader who finds a wrong figure can tell us; we correct it and date the correction.
FAQ
What is the AI API reliability ledger?
A dated, archived ledger of every incident that 11 AI API providers declare on their own public status pages, with one component taxonomy across providers, a coverage window for each provider, and a revision ledger of incidents whose record changed after we first saw it. It was captured on 28 October 2026 and is re-captured weekly.
Is this an uptime measurement?
No. Every figure is what the provider declared. A provider can have degraded service it never posted, and can post incidents that touched few customers. The ledger cannot see either. A later edition adds a small weekly probe, labelled as a snapshot and never as uptime.
Why do some providers show "not covered yet" for 90 days?
Their status pages return only the newest incidents, so the feed itself is shallow. We keep every weekly capture and merge it into the ledger, so depth grows each week. A window the ledger does not yet reach is shown as unknown because a short history is not a clean one.
What is the revision ledger?
Incident records get edited after the fact: a duration shortened, a severity changed, an entry removed. Because each weekly capture is archived and compared with the last, the ledger lists every incident whose published record changed after we first saw it resolved. A change is not evidence of misconduct: providers fix typos, merge duplicates and correct timestamps. The first edition has none by construction.
Why not compare providers as a league table?
Providers list different numbers of components, split them differently, and use different severity labels. Declared minutes are comparable in kind, not exact. Use the ledger to see how one provider changes over time and to compare the shape of incidents, not to crown a winner.
Can I reuse it?
Yes. It is published under CC BY 4.0: reuse is free with attribution to Vincent Wesley Couey and a link to this page.
Does it have a DOI?
Yes. Version 1 is https://doi.org/10.5281/zenodo.23724799. The DOI for all versions is https://doi.org/10.5281/zenodo.23724798.