Uptime Percentage: Why Your Check Interval Caps It
An uptime percentage is a sample, not a recording, and its precision is bounded by your check interval. Here is the arithmetic and why two tools disagree.
An uptime percentage is the share of a period in which a service was reachable, and it is a sample rather than a recording. Its precision is capped by how often something checked. Change the interval and the same month yields a different figure, which is why two honest tools rarely agree about one service.
What is an uptime percentage?
Total time minus unavailable time, divided by total time, multiplied by one hundred. The formula is trivial and every calculator on the web prints it. All the interesting work happens in the word "unavailable", which the formula does not define.
Consider a service that answered cleanly for 29 days, then refused half its requests for six hours. Nobody would call that month perfect. Whether it reads as 99.17% or as 99.58% depends on whether a half-broken service counts as down, and that is a policy decision rather than a calculation.
Why does your check interval cap the number?
Because the figure is assembled from observations, not from a continuous recording. Each check is one data point. When a check fails, the tool charges the entire gap since the previous check as downtime. It holds no evidence about what happened inside that gap. The interval becomes the smallest unit of unavailability the tool can express.
A 30-day month runs to 43,200 minutes. Here is what one failed check costs at each common schedule.
| Interval | One failed check | Finest reading under 100% | Resolution |
|---|---|---|---|
| 30 seconds | 0.5 min | 99.9988% | 0.0012 points |
| 1 minute | 1 min | 99.9977% | 0.0023 points |
| 5 minutes | 5 min | 99.9884% | 0.0116 points |
| 15 minutes | 15 min | 99.9653% | 0.0347 points |
| 60 minutes | 60 min | 99.8611% | 0.1389 points |
Now set that against a target. Four nines allows 4 minutes 19 seconds across a 30-day month. A single failed check on a five-minute schedule already spends more than the entire allowance. That tool cannot report a near miss at four nines. It reports a clean 100% or it reports a breach, with nothing usable between them.
In our testing, a one-minute schedule and a five-minute schedule watched the same endpoint through one four-minute outage. The faster one landed on 99.9907%. The slower one caught a single failed check and billed the whole gap, landing on 99.9884%. Both arithmetics are correct and the services were identical.
Why two tools disagree about the same month
Interval is the first reason and the confirmation rule is the second. A checker that marks a service down on one failed request from one location records blips that a checker demanding agreement from a second region discards. Our own probes run a two-region confirmation before a monitor moves to down, described in cross-region quorum.
Vantage point is the third. A probe in Sydney and a probe in London disagree during a regional routing fault, and each is telling the truth about its own path. Region codes and egress addresses are listed in the probe IP documentation.
The fourth is scope. Some tools subtract announced maintenance from the denominator and some do not, so the same six-hour upgrade either vanishes or costs you a nine.
What has to be true before the number means anything
A percentage without a definition attached is decoration. The clearest published example is Amazon's, which is worth reading precisely because it is so narrow. The AWS Compute SLA subtracts from 100% the share of minutes in which EC2 sat in a state of unavailability. That gives its Monthly Uptime Percentage. Amazon commits to 99.99% at region level as of September 2026.
Read what triggers that clock. Region-level unavailability requires every one of your running instances across two or more availability zones to concurrently lose external connectivity. A single instance dying does not count. The arithmetic is a division, and the definition is doing all of the work.
Google's SRE book makes the complementary point in its availability table. For a service that fails partially, the share of operations failing tells you more than the duration of an outage does.
Common mistakes
Quoting more digits than the interval supports. A figure of 99.995% from a fifteen-minute checker is invented precision. The tool can only land on multiples of 0.0347 points.
Comparing your number to a vendor's number. They measured a different thing from a different place under a different confirmation rule. Compare methods before comparing digits.
Treating slow as up. A request that completes in 40 seconds satisfies most availability checks and satisfies no customer. We prefer to publish a response-time threshold beside the availability figure, which response time monitoring covers properly.
Forgetting who is watching. An outside-in check reports reachability and cannot attribute it. Working out which dependency broke needs metrics gathered on the host.
Pick the interval before you pick the target, because one bounds the other. A team chasing four nines needs checks at a minute or faster simply to describe the result, and anything slower flattens every short outage into a rounding difference. Every plan on the pricing page runs at a one-minute interval or better as of September 2026. At that resolution the uptime percentage you publish is fine-grained enough to argue about.
FAQ
It is the share of a measured period during which a service was available, worked out as total time minus unavailable time, divided by total time, times one hundred. The number is only meaningful alongside three other facts: where it was measured from, how often it was sampled, and what state counted as unavailable.
It allows about 21 minutes and 36 seconds of downtime in a 30-day month. That is a reasonable target for a business application with a human on call, because 21 minutes covers noticing an alert and rolling back a deploy. It is a weak target for a payments or authentication service, where a single lost login window is expensive.
Roughly 1 day and 20 hours across a 365-day year, or about 3 hours 39 minutes per 30-day month. Half a nine sounds close to 99.9% and is not. Dropping from three nines to 99.5% multiplies the allowance by five, which is usually the difference between an overnight fix and a paging rota.
Four reasons, usually in combination. Different check intervals give different resolutions, so short outages round differently. Different vantage points see different network paths. Different confirmation rules decide whether one failed request counts. And some tools subtract announced maintenance from the denominator while others leave it in.
Only if it samples fast enough to resolve the budget. Four nines allows 4 minutes 19 seconds in a 30-day month, so a five-minute checker spends the whole allowance on one failed check and can never report a near miss. A one-minute interval resolves the figure to about 0.0023 points, which is fine enough to be argued about.
Related reading
- Cross-Region Quorum: How Confirmation Stops False Alerts - Cross-region quorum means a target is only called down once probes in more than one region agree. Here is the voting rule, its cost and its limits.
- Response Time Monitoring: Phases, Percentiles, Regions - Response time monitoring works when you read the timing waterfall, alert on p95 instead of the mean, and compare probe regions rather than blending them.
- SLA vs SLO vs SLI: Which One You Have to Build - SLA vs SLO comes down to audience, but the SLI underneath is the only layer you have to build, and its definition decides what the other two mean.