Method and sources

The promise

Every commitment is read off the vendor's own SLA page: the uptime percentage per tier, what it is measured over, the credit schedule, the cap, the claim window and the main exclusions, with a quote of the clause and the version or date the page prints. Where a vendor publishes no SLA, that is recorded as a finding, not a gap. The headline promise of a service is its highest published tier.

The reality

Observed uptime comes from each vendor's own status page, read through its public feed: Atlassian Statuspage and incident.io APIs, Google Cloud's incidents.json and the AWS Health Dashboard history. For vendors without a machine-readable feed, incidents.fru.dev fills in.

• Downtime is the time during which the vendor itself marked a component of the service as a major outage, or rated the incident critical. Partial outages, degraded performance and incidents confined to the console, dashboards, billing, docs or delayed metrics are shown as degraded or left out, not counted. For feeds that never carry component statuses (OpenAI's and Cohere's), an incident the vendor rated major counts.
• Overlapping incidents are merged. One incident counts for at most 72 hours.
• When an incident names a region (in its components or its title), it counts for that region only, and the worst single region is used, since an SLA is per region. Incidents without a region count everywhere.
• Uptime is 1 minus downtime over the covered time, for the last 90 and 365 days. Coverage is how far back the feed reaches; below 80% of the window the number is marked partial, below 7 days there is none.

Promise against reality

Because observed uptime is measured in the worst single region, it is set against the best promise a single-region deployment gets. Tiers that only hold across regions (DynamoDB Global Tables, multi-region WarpStream, dual-region Cloud Storage, geo-redundant Blob reads) exist to ride out a one-region outage, so they are shown with the service but not held against it. Downtime used is compared with the downtime that promise allows over the same covered days, and the months that fell below it are counted, since credits are claimed month by month.

Beside it, a smaller figure from the sister site Downtime, which logs every incident: uptime weighted over all incidents, minor ones included, per vendor. It is always lower and answers a different question (how often something was wrong). This site, Uptime, counts only major outages per service, which is what SLA credits rest on and what the rankings use. In short: Uptime is what vendors promise and how they did; Downtime is every incident.

What it is not

A status page is what a vendor chose to say. Some under-report, some are careful. An outage marked on a component may have hit a few customers, and an SLA's own definition of downtime (error rates, per-resource checks) is narrower than any status page. So observed uptime is evidence to weigh, not a credit calculation for your account. Summaries of published SLAs; the contract you sign governs.

Changes

Sourced changes come from the vendor or from Wayback Machine snapshots that show a different number. Once a month (the first Friday run 27 days or more after the last read) each SLA page is fetched again and compared with the text of the last read. A page whose sentences about percentages, credits, uptime, downtime, response times or exclusions changed is logged as detected and Unverified until reviewed, with a one-line summary by a language model where the budget allows (at most two calls a run), otherwise with whether the promise on file still stands on the page. Navigation, dates and marketing copy moving are not listed, and a read with under half of last time's text is refused.