Why independent uptime measurement matters
If you have ever watched a provider’s status page show green while your alerts fired red, you already know the problem. Status pages are not monitoring tools. They are communication tools — and the incentives behind them are not aligned with accuracy.
The structural problem with status pages
Every major cloud provider operates their own status page. Most are updated manually or semi-manually by incident response teams. The people updating those pages are under pressure: too early an update escalates the incident internally, triggers SLA clock-watching, and invites customer complaints. Too detailed an update reveals architectural weaknesses.
The result is systematic underreporting. Incidents are acknowledged late, scoped narrowly, and resolved on paper before service actually recovers. A provider can honestly report “99.99% monthly uptime” while your workload experienced 47 minutes of degradation — because they measured a different endpoint, from a different region, using a different definition of “success.”
This is not malice. It is structure. The incentives produce the behaviour.
What independent measurement changes
Independent measurement breaks the feedback loop. When a third party runs probes from outside the provider’s own network — against real endpoints, from real vantage points, using the same checks your application would — the data has no agenda.
It cannot be gated by an incident commander deciding whether something is “significant enough” to post. It cannot be scoped to a single region when five regions are affected. It cannot be resolved on the status page before the metrics recover, because the metrics come from outside.
The output is a simple, verifiable record: at this minute, from these five locations, the endpoint either responded or it did not.
How UptimeProject measures
Every service in the leaderboard is measured by five probe agents running on separate networks in Falkenstein (DE), Roubaix (FR), New York (US), Seattle (US), and Singapore (SG). No two probes share an upstream provider. No probe is hosted on the infrastructure it measures — there are no AWS probes measuring AWS.
Each probe runs HTTP, DNS, TLS, and storage checks at per-check cadences — HTTP every minute, DNS every five minutes, TLS once an hour, storage every five to ten minutes. The full table is on the methodology page. Results are streamed continuously to a central database. Availability is computed from probe consensus: a one-minute window counts as “up” only if a strict majority of reporting probes succeeded. A window with fewer than three reporting probes is excluded from the availability denominator entirely — we do not penalise services for our own coverage gaps.
The full methodology is documented and versioned. Every change to how we calculate availability is a git commit you can read.
What this is useful for
Picking a provider. If you are choosing between object storage providers and want more than marketing copy, the leaderboard gives you 90 days of independent measurement across multiple regions and check types.
Validating SLA claims. Providers quote availability numbers in their SLAs. Those numbers are usually self-reported. Our measurements are not. When they diverge, that divergence is interesting data.
Incident context. When something breaks in your stack, it helps to know whether the problem is you or them. A public, continuously-updated record of provider availability gives you external reference data in real time.
Historical patterns. Some providers have excellent average uptime but poor incident recovery — they go down infrequently but stay down longer. Others degrade quietly without ever tripping a full outage. Aggregate availability numbers hide this. Per-minute status history does not.
What this is not
UptimeProject is not a replacement for your own observability. Synthetic checks from external probes will never see what your application-level metrics see. A provider can pass an HTTP health check while your specific API endpoint is broken, your database replica is lagging, or your object storage bucket policy is misconfigured.
Use this data for what it is: an independent, outside-in view of whether a provider’s infrastructure is reachable and responding. That is a narrow but genuinely useful signal — one that providers themselves cannot provide credibly.
The leaderboard is live. Per-minute consensus refreshes every minute; the daily availability table refreshes hourly. All measurements are published under CC BY 4.0 — use them however you like, with attribution.
For the deeper version of why provider-quoted uptime numbers diverge from real user experience, see What 99.99% uptime actually buys you.
Questions or corrections: hello [at] uptimeproject [dot] org