Downtime: What It Means and How to Measure It

Downtime is any period when a system is unavailable to the people trying to use it. That is the computing sense, not the coffee-break one. The definition sounds obvious until you try to put a number on it, because the answer changes depending on where you measured from and how long you waited before deciding.

How is downtime measured?

As a share of a period, from a stated vantage point, using a stated confirmation rule. Miss either of the last two and the percentage means nothing. Wikipedia's entry defines the unavailable period but leaves the measurement method open, which is where most disagreements between vendors and customers start.

The arithmetic is a division, and the familiar nines follow from it directly.

Availability	Unavailable per month	Unavailable per year
99%	7 hours 18 minutes	3 days 15 hours
99.9%	43 minutes	8 hours 46 minutes
99.95%	21 minutes	4 hours 23 minutes
99.99%	4 minutes 23 seconds	52 minutes 36 seconds

Three nines sounds impressive until you read the middle column. Forty-three minutes of downtime is one bad deploy and a slow rollback. The number is far easier to promise than it is to hold.

Planned work is not the same thing

Announced maintenance and unannounced downtime feel identical to a user mid-request, but they belong in different buckets on the report. The usual convention excludes announced work from availability, on the strict condition that the announcement went out beforehand. Keeping that rule in your maintenance window policy stops the bucketing argument from happening during the incident.

Unplanned outages are the ones the metric exists for. PagerDuty's definition covers both internal and external services being unavailable or idle, and internal is worth remembering. A queue worker that stopped consuming is an outage even while the homepage returns 200.

Down for whom, exactly?

This is the question a single checker cannot answer. A service can resolve correctly in London and fail in Sao Paulo, because of an expired certificate on one edge node or a DNS record that propagated unevenly. One probe reporting a failure tells you something failed, somewhere, possibly the probe itself.

We prefer a confirmation rule over a faster trigger. A check moves through UP, SUSPECT, DOWN and then RECOVERING, and a second region has to agree before the DOWN vote counts. A probe error never counts as a failure vote at all. That rule keeps a network problem on our side out of your downtime total rather than in it.

Six regions are available as of September 2026, and their egress IPs are published on the probe IPs page for allowlisting.

Website downtime specifically has a second trap. An HTTP 200 with an error page in the body is a failed request that a naive status-code check records as healthy. A keyword assertion on the rendered response catches it, and costs nothing extra to run.

What the number is actually for

Two things, and neither is a scoreboard. It tells you whether your downtime trend is getting worse, and it tells you how long recovery takes once something breaks. The second half is MTTR, and detection time is buried inside it, so a slow check interval inflates the figure before a human is involved.

A cost-per-minute framing is popular with vendors, and Datto's write-up is a fair example of it. Treat those averages as directional. Your own number depends on your margin and your customers, and an internal tool going dark for an hour is not comparable to a checkout path doing the same.

Reporting an outage honestly means publishing the vantage point alongside the percentage. Say how often you checked, from where, and what counted as a failure. You can put a real figure behind that on the free plan, which covers 10 monitors at a one-minute interval with two-region confirmation as of September 2026. Measuring downtime properly is cheaper than arguing about it later, so start free and let the history do the arguing.