LLM APIs fail differently from ordinary web services, and the standard uptime page captures only the smallest part of it. A provider can report 99.9 percent availability during a period when a meaningful share of production requests did not usefully complete.
Failure Modes That Do Not Register as Downtime
| Failure mode | What the user sees | Counted as downtime? |
|---|---|---|
| Rate limiting under load | 429 errors, retries, delay | Usually no |
| Capacity-driven latency spikes | Timeouts at the application layer | Usually no |
| Silent quality degradation | Worse answers, same latency | No |
| Truncated or malformed output | Broken downstream parsing | No |
| Model version rollout | Behaviour changes mid-deployment | No |
| Regional degradation | Failures for some users only | Sometimes |
| Full outage | 5xx across the board | Yes |
Only the last row reliably makes it onto a status page. For most production systems the top four cause more incidents than the bottom one, and they are invisible in vendor reporting.
Silent Quality Degradation Is the Hard One
Availability and latency are easy to monitor because they are mechanical. Answer quality is not. A provider that swaps a quantisation level, changes a routing policy, or rolls out a model revision can materially change output while every mechanical metric stays green. Teams usually discover it from user reports rather than monitoring.
The mitigation is a small fixed evaluation set run continuously against production, checking output properties rather than availability: does structured output still parse, does a known question still get a known-correct answer, has response length shifted. This is unglamorous and it is the only thing that catches the failure mode.
Building Against It
Five practices. Pin model versions explicitly rather than using floating aliases, so rollouts do not surprise you. Configure a fallback provider for the same or an equivalent model, which is much easier for open weights than for first-party-only models. Set timeouts based on p99 rather than median. Treat rate limits as an expected condition with backoff rather than an error. And log request-level outcomes including malformed output, since that is your only view of the failures the provider does not report.
Multi-provider routing is the structural answer, and it is a substantial reason routers have grown. See OpenRouter usage rankings.
Brand Visibility Implications
Reliability affects measurement more than most teams account for. A brand-visibility measurement run during a degradation window produces results that reflect provider state rather than brand position, and because degradation is often silent, those results look normal. Version-stamp measurements, run them repeatedly rather than once, and treat a single-run number as an estimate. Sudden unexplained visibility movement is worth checking against provider incident history before treating it as real.
Methodology
Compiled from provider documentation, published benchmark suites, and independent measurement through July 2026. Inference performance figures depend heavily on model, quantisation, batch size, context length, and region, so ranges are given rather than point values and cross-provider comparison carries real uncertainty. Re-verify before quoting. Updated quarterly.
How Presenc AI Helps
Presenc AI samples continuously rather than in single runs and version-stamps every measurement, so provider-side variance is visible as variance instead of being mistaken for a change in brand position.