If your application calls even one third-party API, its reliability ceiling is no longer yours to control. That is the uncomfortable truth behind the uptime numbers API Status Check has been tracking since late 2025 across more than 215 services spanning cloud infrastructure, AI, payments, developer tools, and communications.

This is not a ranking exercise. It is a look at the patterns hiding in publicly reported incident data — patterns that reveal which API categories are struggling, how long outages actually last, and what separates teams that ride out upstream failures from teams that wake up to an incident channel on fire.

The Data

API Status Check, an API monitoring platform, analyzed incident reports published on public status pages (primarily Statuspage.io endpoints) for 215+ services across 25 categories from October 2025 through February 2026, pulling incident count, severity classification, time to resolution, and affected components.

Two caveats. This data is self-reported — providers decide what makes it onto their status page and how they classify severity. And uptime estimates derived from incident logs are approximations, not SLA-grade measurements. They tell you where the trouble spots are, not the precise decimal to put in a contract.

Incident Frequency by Category

One of the study’s findings is that API incidents tend to affect different technology categories in different ways. The distribution across categories was not close to uniform: whereas AI-native and cloud platforms experienced trouble, developer tools and payments-related APIs saw higher uptime.

AI and machine learning APIs led by a wide margin. OpenAI logged 11 incidents in 28 days in January 2026 — one every two and a half days. Anthropic posted multiple incidents per week, often scoped to specific models: elevated errors on Claude Haiku 3.5, and a 30-hour resolution cycle for Opus 4.5 in late January. Across 19 AI services, the category averaged more incidents per service than any other.

Cloud infrastructure came second, but with a different character. Rather than frequent small fires, cloud providers tended toward infrequent, high-blast-radius events. The October 2025 AWS DynamoDB incident in us-east-1 cascaded into 141 affected services. Microsoft Azure had three major incidents in 2025, including a 50-hour networking outage. Cloudflare’s November 18 outage — a bug in bot management file generation — took down thousands of websites, including portions of X, OpenAI, and Downdetector itself.

Developer tools (GitHub, Vercel, Netlify, Fly.io) sat in the middle. GitHub averaged four to five incidents monthly in early 2026: a repo creation disruption lasting seven hours with errors peaking at 55 percent, and an authentication failure with API errors up to 22 percent.

Payments were the quietest category. Stripe’s status page was essentially empty across the entire window. When payment incidents occurred — Square and Shopify each had brief disruptions in February — they resolved quickly.

Resolution Times

Another finding is that resolution times are relatively quick, with only a cluster of multi-hour or multi-day incidents, indicating that retaining API uptime is a pressing requirement.

Most incidents were resolved within two hours. OpenAI’s January incidents were mostly cleared in 30 to 90 minutes. Datadog’s critical web UI outage (the monitoring platform going down — the irony) was resolved in 37 minutes. Netlify’s function latency spike lasted 14 minutes.

Multi-hour incidents clustered in infrastructure. Cloudflare’s Chicago network degradation on January 27 lasted seven hours. GitHub’s repo creation failure ran equally long.

Multi-day incidents were rare but devastating. AWS’s DynamoDB incident rippled for 22 hours. Azure’s January 2025 networking failure lasted 50 hours. OpenAI’s Sora capacity issues in April 2025 were not fully resolved for 22 days.

The median resolution across all incidents was roughly 90 minutes. But the distribution is heavily right-skewed: planning for the median will leave you unprepared for the tail events that cause real damage.

Three Outages That Illustrate Systemic Risk

Even though large outages are rare, the recent string of major outages points to systemic flaws. Just take a handful of recent failures and the results as evidence.

Cloudflare, November 18, 2025. A single bug in Bot Management took down Cloudflare’s network, dashboard, and API — along with thousands of downstream services, because Cloudflare sits upstream of so much internet traffic. This is concentration risk made visible: when a handful of providers handle a disproportionate share of the web, one failure mode can take down services with no direct business relationship to each other.

AWS DynamoDB, October 20, 2025. A DNS race condition in DynamoDB cascaded across us-east-1 into 141 services. Atlassian’s Jira and Confluence degraded for 22 hours. The postmortem revealed that cross-region service calls amplified the blast radius even though Atlassian deployed across multiple regions. Implicit dependency chains defeated explicit architectural redundancy.

Google Cloud, June 12, 2025. A bad automated update to Google Cloud’s quota system propagated globally, affecting 76 services for three hours. Nothing was wrong with compute, storage, or networking — the internal access control layer failed. Quota systems, rate limiters, and authentication layers are the nervous system of cloud platforms. When they break, everything downstream breaks.

The AI Reliability Gap

The single clearest finding: AI APIs are significantly less reliable than mature SaaS categories.

Stripe operated at an estimated 99.99 percent uptime. Linear posted 99.96 percent. OpenAI ran at approximately 99.76 percent overall, with API components dipping to roughly 98.89 percent over one stretch. Anthropic showed frequent short-duration incidents.

The cause is structural. AI companies are simultaneously scaling inference infrastructure, launching new models, and handling demand curves that did not exist two years ago. Stripe has spent over a decade hardening a well-understood domain. OpenAI is serving responses from models that change on cycles measured in weeks.

If AI is your core value proposition, you need more resilient architecture than you would for mature APIs. Multi-provider fallback, cached responses for common queries, and graceful degradation paths are not optional.

Patterns Worth Noting

Other patterns in the data are worth noting, too. For instance, management plane failures rarely cascade to the data plane. Vercel’s dashboard went down while sites continued serving traffic. Datadog’s web UI disappeared, but alerting kept firing. Separating the control plane from the data plane is one of the most consequential reliability decisions a platform can make.

Upstream failures are the hardest to plan for. Netlify’s builds broke because GitHub’s authentication failed. SendGrid reported delays caused by Gmail. Your composite SLA is the product of your dependencies’ SLAs, not the average. Five services at 99.9 percent each yield a composite availability of 99.5 percent — over four extra hours of downtime per year.

What to Do About It

Given the trend of recent outages and the cascading failures from upstream outages, there are a number of things consumers can do to future-proof their systems:

• Monitor dependencies independently. Status pages lag reality, sometimes by tens of minutes. Independent API monitoring gives you a signal before your users file tickets.
• Implement circuit breakers. When an upstream API starts failing, stop sending traffic. A breaker that trips after five consecutive failures and backs off for 30 seconds prevents you from cascading a partial upstream failure into a full downstream outage.
• Design a multi-provider fallback where it matters. Most critical for AI APIs given current reliability. If you call OpenAI, have an Anthropic or open-source fallback tested and ready. The switchover does not need to be seamless — it needs to exist.
• Cache aggressively and set tight timeouts. Five seconds is a reasonable timeout for non-streaming API calls. A slow call that hangs for 30 seconds is worse for users than a fast failure with a cached response.
• Calculate your composite SLA. Multiply the SLAs of every service your critical path touches. If the result is uncomfortable, that discomfort is data.

Looking Ahead

The API economy is growing faster than the reliability engineering practices that support it. AI services are the most visible example, but the same tension exists anywhere velocity outpaces operational maturity. The teams that acknowledge this gap and architect for it will build products that survive the 3 AM incident no one predicted.

Reliability is not a feature. It is the foundation that makes every other feature possible.

Incident data sourced from public Statuspage.io API endpoints and official provider status pages for 215+ services across 25 categories. Primary analysis window: October 2025 – February 2026. Uptime estimates are approximations based on reported incident duration and severity.