AI API Uptime in 2026: 31 Claude Incidents in 12 Weeks and What SLAs Promise

Anthropic's own status page logged 31 incidents touching the Claude API between 5 August and 28 October 2026. Most were short, with a median of about 43 minutes, but 15 ran past an hour. If you run a production agent on one model provider, AI API uptime is not a number on a vendor slide. It is a log you can count, and the counts sit badly against contract terms that, for the direct Claude and Gemini developer APIs, promise no uptime at all.

The short answer. Among the three largest model providers, only API access bought through a cloud contract or an enterprise tier comes with an uptime SLA. Google offers 99.5% for Gemini on Google Cloud, AWS implies 99.9% for Bedrock and OpenAI states 99.9% for Scale Tier. Direct access to Claude and the Gemini Developer API carries none.

The reader for this post is the head of delivery or engineering lead who owns an agent in production. You hold the pager when a model provider fails, so you need the incident pattern and the contract terms in one place.

What the AI status pages actually logged in 2026

Every major model provider publishes a status page. Each one is a self-report. The provider decides what counts as an incident, how severe it is, and when it is resolved. That makes the logs useful for patterns and weak for league tables.

We pulled three public sources on 31 October 2026. Anthropic's page runs on Atlassian Statuspage and exposes a JSON feed of its 50 most recent incidents. OpenAI's page lists incidents back to 4 August 2026 and labels October entries by impact. Google publishes a Cloud-wide incident feed that tags affected products, including the Vertex Gemini API.

Neither Anthropic nor OpenAI exposes January to July 2026 in a form we could read. Anthropic's feed starts on 5 August and OpenAI's history starts on 4 August. We therefore kept one common window of roughly 12 weeks rather than mixing complete and partial months. A monthly table built from January would have been padded with third-party tracker counts, and those trackers disagree with each other.

For Anthropic, an incident counts as an API incident if its component list includes the Claude API. For OpenAI, it counts if the title or listed components name an API surface, such as Responses, Chat Completions, Agents or Files. Durations are wall-clock time from when the incident was opened to when it was marked resolved. That is not the same as the minutes your requests failed, and we return to the gap below.

Claude API incidents, month by month

Anthropic's feed lists 50 incidents in the window. Of those, 31 list the Claude API as affected. The rest touched claude.ai, Claude Code, Cowork or the developer console without the API. The two longest entries in the feed, at roughly 149 and 99 hours, were console and Cowork problems that left API traffic alone.

Sources: Anthropic incident feed, OpenAI status history and October impact labels, Google Cloud incident feed, all retrieved 31 October 2026. OpenAI's API-named count uses titles for August and September, where component lists were not available, so those two months are likely undercounted. Columns are not comparable across providers, because each one decides what it posts.

Short, frequent and model-specific

The median Claude API incident lasted about 43 minutes from open to resolution. Fifteen of the 31 ran past an hour, and 4 ran past 3 hours. The longest was a 7-hour "degraded performance of multiple models" entry on 5 August. A 6-hour October entry concerned delayed credits on the Claude Platform, which is a billing problem rather than a serving one.

The titles tell you more than the counts. Of the 21 incidents labelled major or critical, 11 named one or two specific models, such as Claude Sonnet 5.5 or Claude Opus 5.5. Another 3 named three models, or one model "and other models". Only 7 were described as multiple models or a broad service disruption. We think that ratio is the most useful number in this post for anyone designing failover.

Incident time is not downtime

Summed wall-clock incident time for the Claude API was 48.9 hours across the window. That equals roughly 2.4% of the hours between 5 August and 28 October, but it is an upper bound on exposure, not a downtime figure. An "elevated errors" incident on one model may fail a small share of requests while every other model serves normally. Anthropic's own update text often gives a narrower impact window than the open-to-resolve span.

OpenAI's incident log and its 99.97% uptime figure

OpenAI's status page lists 102 incidents between 4 August and 31 October 2026. By our title-and-component rule, 27 named an API surface, and two more are borderline. October is the only month with impact labels in the public feed. Of 25 labelled October incidents, 4 were major, 18 minor and 3 carried no impact label.

Only one of those four major incidents named the API. On 20 October, users "near Illinois experienced authentication errors with the API, ChatGPT, and Codex" for about an hour, according to OpenAI's postmortem text. The other three were ChatGPT and workspace problems.

Why 102 incidents and 99.97% can both be true

The same page shows 99.97% uptime for the APIs group, with Chat Completions and Responses each at 100%. Uptime there is computed from component status, so an incident that degrades one model on one endpoint may never flip the component to an outage state. Over roughly 89 days, 0.03% is about 38 minutes of counted downtime.

Our view is that this is the single most misleading number a buyer will be shown. It is not false. It answers "was the component marked down?", while your agent cares about "did my calls to my model fail?". On 22 October, OpenAI logged 6.5 hours of elevated Responses API errors, and the Responses component still shows 100% for the window.

Gemini API outages: a thin public record

Google's record is the hardest to read, and the reason is structural. The Gemini Developer API, used through AI Studio keys, has a status page that renders in JavaScript, and we could not extract an incident history or uptime figure from it. Gemini sold through Google Cloud reports into the Cloud-wide incident feed instead.

That feed lists 8 Google Cloud incidents in 2026, starting from 27 February. One names the Vertex Gemini API. On 27 February, customers saw 429 and 503 errors on the global endpoint for 1 hour 58 minutes. Google traced it to "a configuration change to a safety filtering service that supports all Gemini models" and rolled the change back.

Do not read that single entry as a reliability win. Google's Cloud feed appears to post incidents at a much higher threshold than Anthropic's model-level page does. A provider that posts less looks better on any count, which is the exact opposite of what a buyer should reward. We would rather see a provider post 30 short incidents than 1 summary.

LLM API SLA terms compared

An SLA, or service level agreement, is a contractual uptime target with a defined remedy, usually service credits, when the provider misses it. The status page tells you what happened. The SLA tells you what you are owed, which for most direct API buyers is nothing.

Sources: Anthropic commercial terms and service tiers documentation, Gemini API additional terms, Google Cloud Gemini SLA (25 June 2026 version), OpenAI Scale Tier page, AWS Bedrock SLA (updated 4 October 2023). OpenAI's standard services agreement could not be retrieved for this post, so the standard OpenAI tier is omitted rather than guessed.

Read the definition of downtime before the percentage

The headline number matters less than how an outage is measured. AWS calculates Bedrock availability in 5-minute intervals and counts as an error only a request that "returns a 500 error code". Google's Gemini SLA has, across its published versions, defined downtime as a server-side error rate above 5%, and ignored intermittent periods under 5 minutes. Rate-limit responses and slow answers fall outside both.

Many of the incidents in the logs above were exactly that kind of event: elevated latency, degraded performance or partial errors on one model. An SLA written around hard 500 errors would pay nothing for most of them. If you run long agent loops, slow is often as damaging as down, and no contract we read prices it.

The credit is not the compensation

Every remedy we found is a credit on future bills, capped, and claimed by you with your own logs. AWS issues nothing under $1 and makes the credit the "sole and exclusive remedy". A 10% credit on one month of inference spend will rarely cover the cost of an agent that stopped taking customer tickets for an afternoon. Treat the SLA as a signal of provider discipline, not as insurance.

Incident hours against each SLA's downtime budget

Turning a percentage into minutes makes the gap concrete. A 30-day month has 720 hours. At 99.9% the provider may be down for about 43 minutes before credits apply. At 99.5% the allowance is 3.6 hours. OpenAI's displayed 99.97% equals about 13 minutes a month.

August's 25.7 hours of open Claude API incidents is about 7 times the 99.5% monthly allowance. We do not claim Anthropic missed a target, because the direct API has none and incident time is not downtime. The point is narrower. Status pages and SLAs measure different things, and neither measures your success rate.

That leaves you as the only party measuring what matters. Your own request logs, broken down by model and error class, are the only record that can show whether a month was 99.9% or 97% for your workload. We covered how to instrument that in the comparison of LLM observability tools.

Where this comparison is weakest

The data base here is three self-reports with different posting rules, and that is the largest weakness. Anthropic posts model-level incidents freely. OpenAI posts often but labels only recent entries. Google posts to a Cloud-wide feed with a high bar. A raw count rewards the least transparent provider, so we have refused to rank them.

The window is short and partial

Twelve weeks is not a year. We could not read January to July 2026 from any official source in machine-readable form, so seasonality and large spring incidents are missing. Anthropic's August column starts on the 5th, and its feed caps at 50 entries. A provider with a bad quarter followed by a quiet one would look very different on another window.

Our classifications are judgement calls

Counting an OpenAI incident as "API" relied on titles for August and September, which almost certainly undercounts. Sorting Claude incidents into one-model and multi-model buckets relied on titles too. Several older Claude incidents came from a summarised copy of the feed rather than the raw file. We think the direction is right and the exact counts could move by a few in either direction.

There is also a fair competing view. Some engineers argue that status-page counts are noise and that only third-party synthetic probes give a comparable uptime figure. They are partly right. Probes measure the same thing the same way across providers, which status pages never will. Probes also miss model-specific degradation unless they call every model, and few do.

What this means for a single-provider production agent

The pattern in the logs is many short, model-specific incidents and a handful of broad ones. That shape argues for two layers of defence, and the cheap layer handles most of the risk. We would build the first layer before negotiating any contract.

Same-provider model fallback first

Because 11 of 21 serious Claude API incidents named one or two models, a router that switches from Sonnet to Opus, or between model versions, would have kept many agents serving. This costs little if you already evaluate both models. The quality trade-off is real, and the analysis of model routing quality gaps shows where cheaper or older models fall short on the same task.

Cross-provider or cross-cloud failover second

The 7 broad incidents are the ones a sibling model cannot absorb. For those you need a second route, either another provider or the same model through a cloud such as Bedrock. The second route only works if the prompts, tool schemas and output parsing have been tested against it, which is where the real switching costs between model providers show up. Gateways can automate the routing, at the fees laid out in the AI gateway fees and failover comparison.

Our stance is plain. If an agent's downtime costs you revenue, direct API access with no SLA is the wrong default for that workload. Buy the cloud route with a credit table, keep the direct route for development and overflow, and write both into your agent on-call runbook. Contract levers beyond uptime are covered in the comparison of model provider terms.

Frequently asked questions

Where to start this week

Pull your last 30 days of model API logs and compute one number per model: the share of requests that returned an error or exceeded your latency ceiling. Put it next to the provider's status page for the same month. If your number is worse than theirs, you have found the gap this post describes, in your own workload.

Then check which route your revenue-earning agent actually uses. If it is a direct key with no SLA, price the same model through a cloud contract and decide whether the credit table is worth the change. That decision takes an afternoon, and it is cheaper than making it during an incident.

Related reading