Why we will never quote you an uptime percentage
Every monitoring tool you have ever evaluated leads with a number like 99.98%. It appears on the dashboard, in the monthly email, and in the report you forward to your client. It looks like a measurement. It is an estimate, and most of the time nobody says so.
Where the number comes from
A monitoring service does not watch your site continuously. It cannot; nothing can. It visits on a schedule — every minute, every five minutes, every fifteen — and records what it found each time.
To turn those visits into a percentage, it counts the failures, divides by the number of visits, and presents the result as though it described the whole month. One failed check out of 8,640 becomes “99.99% uptime”.
That arithmetic contains a silent assumption: that the site’s condition between two visits was the same as its condition during them. It usually was. Sometimes it very much was not.
Two ways the number lies
It hides outages shorter than the gap. If a site is checked every five minutes and goes down for three, there is a good chance no check ever landed on it. The month reports 100%. Real visitors got errors. The number is not merely imprecise — it is confidently wrong in the direction that flatters the tool.
It turns one bad sample into a suspiciously exact figure. Go the other way: a single failed check out of a few thousand produces 99.97%. Two decimal places, from one observation that may have been a momentary blip, a slow DNS response, or the monitoring service’s own bad afternoon. The precision is manufactured entirely by the division.
The part that should actually worry you
Both of those are tolerable if everyone understands they are looking at a sample. The problem is the last step, where the number leaves the dashboard.
You forward it to your client. It goes into a report with your logo on it. And at that point “a sampled estimate produced by a third party’s arithmetic” has quietly become your assurance that their website was up 99.98% of the time last month.
If that client ever has a bad morning — a failed checkout, an angry customer who could not reach them at 9am — that number is the first thing they will bring back to you. You will not be able to defend it, because you did not compute it and it was never a measurement.
What we do instead
Plumbline reports what it observed, and says how it observed it. A monthly report opens with a sentence like:
We checked 3 sites 12,960 times during August 2026 and found 1 confirmed problem, listed below.
Then the problem, with the times we first saw it, confirmed it, and saw it working again. Then a table of how many checks of each kind succeeded and failed. And then, at the bottom, in the report your client reads:
The numbers above count checks, not minutes. Each site is visited on a schedule, so a problem that starts and clears between two visits would not appear here.
Every one of those statements is true and defensible. If your client asks where a figure came from, the answer is a list of things we actually did, at times we can name, with the request and the response still stored.
The objection, and the answer
The obvious objection: a percentage is easier to put in a report. One number, big and green, versus a paragraph explaining what a check is.
True. But consider what the percentage is doing for you. It is compressing a month of observation into a figure whose main property is that it always looks good — 99.9% is the floor, not the achievement. Your client cannot tell a good month from a bad one by looking at it, which means it cannot demonstrate the thing you are trying to demonstrate.
“We checked this site 4,318 times last month and it answered every time except twice, both on the 14th, and here is when it came back” is a harder sentence to write and a much better one to be asked about.
Where this rule came from
It is written down in the repository as a decision, dated and argued, under the rule that governs everything else here: describe what Plumbline observed, not what we wish it guaranteed. It is not a “not yet”. There is no roadmap item where we add uptime percentages once we have enough data. More data would not change what the number is.
If a competitor quotes you one, the useful question is: how often do you check, and what happens to an outage shorter than that? The answer tells you exactly how much the number is worth.