Foundation-model uptime in 2026: the 24-month outage record across Anthropic, OpenAI, Google, AWS Bedrock, and Azure OpenAI

Bottom line. Foundation-model providers publish status pages that report on the model API as if it were one service. The 24-month operational record across Anthropic, OpenAI, Google, AWS Bedrock, and Azure OpenAI does not support that framing. Every major provider had at least one multi-hour outage that exceeded their own SLA-credit threshold. The procurement-defensible posture in 2026 is multi-provider routing with documented failover and hard-dollar incident liability above the standard SLA-credit cap, not a single-provider preferred-vendor architecture.

If you run agentic AI procurement for a mid-market or enterprise organisation in 2026, the foundation-model selection decision still tends to be framed as a feature-and-pricing comparison: Anthropic vs OpenAI vs Google for the API, with AWS Bedrock and Azure OpenAI as the hyperscaler-mediated alternatives. The comparison is not wrong, but it skips a procurement layer that is now load-bearing — the operational reliability record of the provider against a production workload, not against a marketing benchmark.

This piece walks the 24-month outage record across the five providers, the SLA-credit gap that almost every enterprise customer discovers only after their first incident, the multi-provider routing patterns that emerged in 2025-2026 as procurement-defensible mitigations, and the contract language additions that the 2026 AI MSA red-team checklist now requires.

The publication tracks this on a 30-day Holding-up cadence. The reliability record is the kind of evidence that ages monthly, not quarterly, and the procurement-defensible posture has to refresh against the most recent operational data the providers publish on their status pages.

Why single-provider dependency is the 2026 procurement risk

The default 2024-vintage agentic AI deployment selected one foundation-model provider, integrated against the provider’s API, and treated the provider’s SLA as the operational ceiling. The architecture compiled. It shipped. It worked for many enterprises across many workloads through 2025.

It also produced the 2025 operational pattern that is now visible in published incident reports: when the chosen provider had a multi-hour outage, the customer’s production agent was non-functional, the customer’s customer was non-functional, and the customer’s revenue stream paused for the duration of the incident. The SLA credit (typically 25-50% of monthly fees on the affected service) did not cover the operational impact. The vendor’s status page reported the incident accurately. The procurement contract had no recourse beyond the credit.

Across the 24-month window May 2024 to April 2026, every major foundation-model provider had at least one such incident. The specifics vary by vendor and by month, but the structural pattern is consistent. A multi-hour outage occurred, the SLA credit applied, the customer’s incident bridge ran for the duration, and the customer’s procurement team subsequently asked the same question: why was a single provider’s status page on the critical path of a production workload?

That question has a procurement answer in 2026, and it is not “pick the more reliable provider.” All five providers have had material incidents. The procurement answer is that the architecture has to assume failure across the provider graph and instrument against it. Single-provider dependency is the failure mode; multi-provider routing is the mitigation.

Reading vendor status pages correctly

A vendor status page reports the operational state of the API gateway and the regional infrastructure surrounding the model. It does not report the operational state of the specific model the customer integrated against. A customer running production traffic through Claude 3.7 Sonnet during a Sonnet-specific degradation can be told by the status page that the API is “operational” while their production agent is returning errors or degraded responses.

This is not a vendor failure. The status page reports what it reports, and the vendor’s monitoring is anchored on the gateway and regional layer because that is where most outages historically clustered. The procurement gap is that the customer’s operational metric is not the gateway’s uptime; it is the specific model’s uptime against the specific prompts the customer’s workload sends. That metric is not on the status page.

The procurement-defensible posture is to instrument the customer’s own observability stack against this gap. The agent observability cluster (claim AM-123) walks the four-platform decision; the relevant procurement signal here is that the observability platform must capture per-model latency, per-model error rate, and per-model degradation patterns separately from the gateway’s published metrics. A customer that relies on the vendor’s status page as its operational signal has no leading indicator of model-specific issues until the production traffic itself reveals them.

The SLA-credit gap

The standard published SLA across major foundation-model providers commits to 99.9% monthly availability with credits capped at 25-50% of monthly fees on the affected service. The arithmetic on 99.9% is roughly 43 minutes of allowed monthly downtime; the arithmetic on the credit cap, for an enterprise paying an indicative $50,000/month against a single provider (source:“our-estimate”), is a maximum of $25,000 returned in the worst month, a fraction of the operational impact a multi-hour outage produces on a customer-facing workload.

Enterprise agentic deployments running customer-facing workloads typically need 99.95% availability with hard-dollar incident liability above the SLA-credit cap, not service credits as the only remedy. The 0.05% gap is roughly 22 minutes per month of additional downtime tolerance, material on a workflow where every minute of downtime translates to a measurable customer impact.

Negotiating up from 99.9% to 99.95% is contractually possible at the Enterprise tier of every major provider. The negotiation requires three procurement instruments: a documented business impact analysis showing the per-minute cost of downtime, a named incident severity tier framework with response-time commitments per tier, and an explicit hard-dollar liability ceiling that exceeds the SLA-credit cap. Most procurement teams discover the gap between the standard 99.9% and the workload-required 99.95% only at month 18 when the first multi-hour incident lands. The procurement-defensible read in 2026 is that the enterprise tier is the only tier suitable for production agentic deployments and that the 99.95% negotiation is required before contract signature.

The 24-month pattern across five providers

The published incident records across the five major providers, read together, produce a pattern rather than a ranking. No provider has been outage-free across the 24-month window. Each has had at least one incident severe enough to surface in mainstream tech press; several have had longer-duration regional incidents that were resolved within the SLA window but materially impacted customer workloads.

Anthropic publishes incident notes at status.anthropic.com and the engineering blog posts incident postmortems for the more significant events. The operational pattern across 2024-2026 is a small number of multi-hour incidents per year, typically affecting a specific model version or region, with detailed postmortems published within 7-14 days.

OpenAI publishes at status.openai.com. The operational pattern includes the broader incident class of credential-system or quota-system failures that affect the entire API surface, alongside model-specific incidents. The credential-system incidents are particularly procurement-relevant because they cannot be mitigated by switching models within the same provider.

Google (Gemini API) publishes at status.cloud.google.com within the broader Google Cloud Platform status surface. The operational pattern inherits the GCP regional fault-domain structure; Gemini-specific incidents are reported but require the customer to filter the broader status feed.

AWS Bedrock publishes at the AWS Service Health Dashboard. The operational pattern inherits AWS regional infrastructure plus Bedrock-specific model availability across regions. Bedrock customers benefit from cross-region inference patterns that mitigate single-region failures within the provider but do not mitigate Bedrock-wide incidents.

Azure OpenAI publishes at the Azure Status Dashboard. The operational pattern inherits Azure regional infrastructure plus the Azure-OpenAI integration layer. Azure OpenAI customers can deploy across multiple Azure regions for failover; that pattern mitigates regional incidents but does not mitigate the OpenAI-side issues that propagate through the Azure integration.

The procurement-relevant read across all five is that the published status pages are the right starting point but are not sufficient. The customer’s own observability layer has to instrument per-model, per-region, per-prompt-class metrics that the vendor status pages do not capture, and the customer’s incident-response runbook has to assume the status page may report “operational” while the customer’s production traffic is degraded.

The three multi-provider routing patterns

Three architectural patterns dominate 2026 production deployments that have moved past single-provider dependency.

Pattern 1: gateway abstraction. A gateway sits between the application and the foundation-model providers and routes traffic based on configurable rules. LiteLLM is the open-source reference implementation; OpenRouter and Portkey are commercial alternatives. The gateway provides a unified API surface that the application integrates against, with the underlying provider selection happening at routing time. Failover is observable, configurable per route, and testable in production. The procurement-defensible benefit is that the customer owns the routing logic and is not dependent on the vendor for failover capability.

The implementation cost is real. The gateway becomes part of the customer’s operational substrate, with its own observability requirements, its own latency overhead (typically 50-150ms added per request), and its own change-management discipline. Enterprises running this pattern typically deploy the gateway in their own VPC with redundancy across availability zones, treating it as production-critical infrastructure equivalent to an API gateway or service mesh.

Pattern 2: provider-side regional failover. Within a single vendor, the customer deploys across multiple regions and handles failover at the regional level. AWS Bedrock cross-region inference and Azure OpenAI multi-region deployment are the two production-grade implementations of this pattern. The pattern is partial mitigation: it addresses regional failures within the vendor’s fault domain but does not address vendor-wide incidents. A Bedrock-wide outage affects all regional deployments simultaneously.

The cost is lower than Pattern 1 because the customer stays inside one vendor relationship and the failover is partly automatic. The procurement-defensible read is that this pattern is appropriate for workloads where vendor-wide incidents are tolerable but regional incidents are not, a narrower set of workloads than most enterprises initially assume.

Pattern 3: explicit multi-provider provisioning at the application layer. The application is built to support two or more model families, with prompt-tested compatibility maintained as a deployment requirement. The customer maintains active provisioning with a primary and secondary provider; failover is application-driven. The pattern is the most expensive to maintain (every prompt change requires testing across the supported providers) and the most resilient (no shared failure mode with the gateway or any single vendor’s regional architecture).

The procurement-defensible read is that Pattern 3 is appropriate for high-availability customer-facing workloads where the per-incident cost exceeds the maintenance overhead of multi-provider support. Pattern 1 (gateway abstraction) is the procurement default for most enterprise workloads in 2026; Pattern 3 is the higher-rigour option for the workloads that justify it.

What changes in 2026 procurement language

Three additions to the AI MSA red-team checklist (the RES-005 checklist covers the broader clause families) are now procurement-defensible asks.

Hard-dollar incident liability above the SLA-credit cap. The standard SLA-credit cap covers a fraction of operational impact. Enterprise contracts in 2026 should require named incident severity tiers (typically four tiers: Sev-1 customer-impacting, Sev-2 degraded service, Sev-3 minor impact, Sev-4 informational), per-tier response-time commitments, and an explicit hard-dollar liability ceiling that exceeds the SLA-credit cap by a multiplier reflecting the customer’s per-minute downtime cost. The negotiation is harder than the SLA-credit negotiation but is achievable at the Enterprise tier of every major provider.

Non-degradation clauses covering model-deprecation events. The vendor’s right to deprecate or update models is the customer’s procurement risk. The 2026 standard is a contractually defined transition window (typically 90 days for major version changes, 30 days for minor) during which the customer’s prior model version remains available alongside the new version. The clause is required because the alternative — forced cutover with no transition window, produces a regression-test sprint the customer’s engineering organisation cannot consistently absorb on the vendor’s schedule.

Right to multi-provider routing without contract penalty. Some 2024-vintage MSAs included vendor-exclusivity clauses that prohibited the customer from routing identical traffic through a competitor’s model. Those clauses do not survive 2026 procurement diligence because they make Pattern 1 and Pattern 3 above contractually infeasible. The procurement-defensible language explicitly preserves the customer’s right to deploy multi-provider architectures and prohibits the vendor from using identical-traffic-routing as a basis for contract enforcement action.

The three additions together are the procurement signature of an enterprise that has read the operational record and is contracting against it rather than against the vendor’s marketing materials. They are not anti-vendor positions; they are the procurement-defensible posture for any enterprise running production agentic workloads in 2026.

What this piece does not claim

This piece does not claim that any single provider is materially less reliable than the others. The 24-month operational record across the five providers does not support a single-vendor ranking. The procurement-relevant read is that the architecture must assume failure across the provider graph regardless of which provider is chosen.

This piece does not claim specific incident counts or specific outage durations as quantitative facts. The published status pages are the source of record; the count and duration of incidents change as the providers update their incident logs. The publication tracks the operational record on a 30-day Holding-up cadence and updates the analysis as the published data shifts. Procurement teams citing specific incidents should cite the vendor status page as the primary source rather than this piece.

This piece does not claim that multi-provider routing is appropriate for every workload. Workloads where vendor-wide incidents are tolerable, where the per-incident cost is below the maintenance overhead of multi-provider support, or where the application is not customer-facing can defensibly run single-provider with appropriate observability and incident response. The procurement-defensible read is to make the architectural choice explicitly against the workload’s reliability requirements rather than as a default that drifts in over time.

What changes this read

Three triggers would shift the analysis. A foundation-model provider publishing a sustained 99.99% operational record across 12 consecutive months, closing the gap between the standard 99.9% and the enterprise-required 99.95% — would change the multi-provider posture from default to optional. A regulatory development requiring multi-provider provisioning for high-risk AI deployments under the EU AI Act or comparable framework would shift the procurement question from architectural choice to compliance requirement. A landmark vendor outage producing material customer harm and follow-on litigation would shift the SLA-credit-vs-hard-dollar-liability negotiation from one Peter could lose to one procurement teams could win without exceptional pressure.

We will re-test against the Anthropic status, OpenAI status, Google Cloud status, AWS Service Health, and Azure status records on or before 4 Jun 2026.

The companion procurement reading is the 60-question agentic AI RFP (claim AM-026) where the foundation-model selection sits as one of the GAUGE governance dimensions. The RFP’s reliability section now includes the three contract additions above as procurement-defensible asks; previous versions did not.