How uptime is measured: our methodology and its limits

Start with the limits

1. A single vantage point -- measured from our server, which is not your network
2. Judged per day -- several samples within a day are collapsed into one daily verdict, which is coarse
3. Samples must accumulate -- a site that just came online has too few samples, so we show a public-dataset baseline
4. Reachability only -- it does not measure output quality or silent downgrading

When you see 96.7%, read it as the share of days it was reachable under this methodology, not as this site being good 96.7% of the time.

The methodology in detail

Judged per day, not per request

uptime = reachable days / total days

Reachable means at least one probe succeeded that day.

Why it is designed this way: measured per request, almost every site converges on 100%, because most requests succeed. The numbers stop separating sites and the metric loses its discriminating power.

A daily verdict separates a site that was down for a whole day from one that was never down.

Side effect: values cluster tightly, since no site reaches 99.9%, so we use stability tiers as the primary signal:

The tier is more meaningful than the precise number. The difference between 96.7% and 96.5% means nothing, but the difference between stable and volatile does.

The source is always labelled

Why the label matters: our principle is to keep measured figures and external data apart. Presenting external data as your own measurement is a common and harmful practice.

Once enough samples accumulate, the presentation switches to measured by us automatically.

Why samples must accumulate

If a monitoring system that just went live computed uptime from a single sample on day one, the result would necessarily be:

1 success -> 100%
1 failure -> 0%

Both numbers are distortions. So we set a minimum sample threshold. Below it we keep the public-dataset baseline and label the source.

This also means that a site showing data from a public dataset does not have a problem, it just means our own sample is not yet sufficient.

How you should use this data

Usable: comparing stability tiers across sites, since relative ranking under one methodology is valid, and watching a tier change over time, since a downgrade is a signal.

Not directly usable: treating uptime as an SLA commitment, because it is an observation and not a promise; drawing conclusions from a single latency reading; or comparing across different methodologies.

What is more reliable

If your business depends on availability, do not rely on any third party's monitoring alone, ours included:

1. Build a lightweight probe of your own. Request from your own server every few minutes and record the success rate. This data is the most relevant, because it measures your path.

2. Cross-check with our data. If your own failure rate is clearly higher than ours, the problem may be on your side of the network.

3. Watch trends rather than absolute values. A site dropping from stable to volatile matters more than which tier it currently sits in.

Related reading

• Reading a relay service's response latency: one measurement is not the experience
• Give a relay service a health check: a 20-minute verification checklist
• After you have chosen: how to keep monitoring your API provider