Which AI provider has the best uptime?

Measured continuously · last verified October 28, 2026

Independent, third-party measured availability for 46 AI inference APIs — including OpenAI, Anthropic, Google, Mistral, Groq and DeepSeek — probed directly from 4 regions every five minutes, not read off a status page and not routed through a gateway. As of October 28, 2026, 33 of 46 providers answered every probe over the last 24 hours (53,046 checks); over the full observation window since 2026-07-28 that is 4,802,895 checks. Availability can vary by region: doubao sits at 99.9% on average but 99.7% from Asia (Tokyo).

AI API uptime comparison — OpenAI, Anthropic, Google, Mistral, Groq, DeepSeek and 40 more

Two windows on purpose: 24 hours answers “is it working now”, the 92-day column answers “is it reliable”. Observation started 2026-07-28; the raw series is retained for 90 days, so this window grows until it reaches that. Providers measured in all 4 regions only. Ties broken by sample size: 100% over 200 probes is a stronger claim than 100% over 20. Detected outages and incident history

Which AI providers dropped requests?

A provider can be perfect on average and still be unreliable for you: what matters is the region your traffic comes from, which is why the worst region is shown next to the average.

Does AI API availability differ by region?

Yes, and by more than the headline numbers suggest. The same providers are probed from every region on the same schedule, so a gap between rows is a property of the path to the provider, not of different sampling. Over the last 7 days:

Asia (Tokyo) failed 2.9× more often than South America (São Paulo) (0.450% against 0.154%) across identical requests to identical endpoints. A monitor that probes from a single location — which is what most uptime dashboards are — cannot see this difference at all, and will report whichever number its own vantage point happens to produce.

How many AI providers had at least one failure this week?

38 of 46 tracked providers dropped at least one probe in the last 7 days — against 13 of 46 in the last 24 hours. That gap is the whole point of looking at more than a day: at 24-hour resolution almost everything reads as 100%, and the failures that do matter are rare enough to hide inside a short window. Availability figures quoted without a window length are not comparable to anything.

Which providers publish a machine-readable status feed?

Only 11 of the 46 providers measured here expose a status feed a program can read. For the rest there is nothing to check a failure against: no feed, no timestamps, no components — which is worth knowing before you plan a fallback around someone’s status page. Where a feed does exist, we compare our observations against it on the incident log, and both outcomes are informative: a matching entry means two independent records agree, a missing one means we saw a failure their page never mentioned.

What does latency add to the uptime comparison?

Here is the same fleet measured on speed instead. Over the last 24 hours the fastest endpoint answered in 70 ms (openrouter) and the slowest in 1423 ms (hunyuan) — a 20.3× spread in measured latency.

Over the last 24 hours we recorded 53,046 probes across 46 providers and 4 regions. Uptime shows whether an endpoint answered; latency shows how long it took.

What still varies by a wide margin is how fast the same provider answers depending on where the request starts — often by several times for identical infrastructure. That difference is measurable, persistent, and it affects every request you make. See the cross-region latency summary.

Observed availability vs published SLA

The figures above are observed availability, not an SLA. They report the share of probes that received a valid HTTP response from the provider’s official API host, measured from outside their network. A published SLA is a contractual promise — usually enterprise-only, measured by the provider, and often excluding exactly the failure modes a client notices first. Neither number substitutes for the other, and this page deliberately does not restate vendor SLA percentages: we publish what we measured, and the contractual terms are the vendor’s to state.

Is there an independent third-party monitor for LLM API uptime?

This is one. Two properties are what make third-party monitoring worth anything, and both are checkable here: probes run directly against the provider’s own endpoint, never through an aggregator or gateway that would attribute its own failures to the provider; and they run from 4 regions at once, which is the only way to separate a provider outage from a broken network path. Monitors built on status-page polling inherit the provider’s blind spots by construction — they can only report what was already admitted.

Compare the uptime of two specific providers

Each pair below has its own page: observed availability for both, the worst region for each, and latency per region side by side.

• anthropic vs openai uptime and latency
• anthropic vs google uptime and latency
• google vs openai uptime and latency
• cerebras vs groq uptime and latency
• deepseek vs openai uptime and latency
• groq vs sambanova uptime and latency
• fireworks vs together uptime and latency
• mistral vs openai uptime and latency

Where does this data come from?

Independent probes in 4 regions open a real connection to each provider’s official API host every five minutes and record whether it answered and how quickly. Requests go directly to the provider, never through a gateway or aggregator, so nothing is attributed to the wrong party. The method and its limits are on the methodology page; raw figures are available as JSON under CC BY 4.0.