Your Uptime Report Is Lying to You (a Little)
Uptime reports are one of the most persuasive documents in IT — clean percentages, green
rows, "99.9% availability this month" printed in a font that suggests certainty. They're also,
in a quiet and mostly unintentional way, not telling the whole truth. Not because anyone's
lying outright, but because "up" and "working properly" are two different claims, and most
reporting only ever measures the first one.
What "up" actually means
Ask most monitoring tools whether a device is up, and here's what they're really checking:
does it respond to a ping, or answer on the expected port, within some timeout window. That's
a real and useful signal — a device that fails that check is genuinely unreachable, and that
matters. But it's a binary answer to a question that, in the real world, has a lot more
texture to it. A device can pass that check and still be a miserable experience to actually
use.
Picture a NAS drive that responds to every ping in under a second but is dropping a third of
its packets. By an uptime check, it's up. By anyone actually trying to open a file from it,
it's infuriating — timeouts, retries, that particular kind of slowness that makes people
assume their own laptop is broken before they think to blame the network. None of that shows
up as downtime. All of it shows up as a support ticket eventually, usually with someone
frustrated enough that "it's been doing this for days" comes out in the first sentence.
The gap between the report and the experience
This is where uptime reports quietly mislead, even with the best intentions behind them. A
99.9% uptime figure is reassuring precisely because it implies the other 0.1% was the only
part that wasn't fine. But a device that's technically reachable the entire month while
dragging along at 40% packet loss for three days of it will show up as effectively 100% on
that report — and it will have been a genuinely bad three days for whoever depended on it.
The number is accurate. It's just answering a narrower question than the one anyone actually
cares about.
This isn't a criticism of measuring uptime — it's a real, meaningful thing to track. The
problem is treating it as if it's the whole picture, because the gap between "technically
reachable" and "actually usable" is exactly where most day-to-day frustration with a network
actually lives, and it's largely invisible to anything that only asks a yes-or-no question.
What response quality actually catches
NetMon tracks latency and packet loss continuously for everything it monitors — not as a
supplement to uptime, but as a first-class signal in its own right. A device doesn't need to
go offline to matter. If its response quality drops out of healthy territory — degrading,
not just down — that's tracked, reported, and for the devices where it matters most (a NAS, a
VOIP phone, a printer, a router, anything running an RMM agent), it's enough on its own to
raise a ticket, independent of whether the device ever technically goes down.
That distinction is deliberate, not incidental. A device flickering between "reachable" and
"barely usable" for hours is often a worse experience than one that goes cleanly offline for
five minutes and comes back — a clean outage is at least obvious and gets escalated instantly,
while flapping response quality tends to get blamed on everything except the actual network
until someone finally checks. Response-quality monitoring exists specifically to catch the
version of "broken" that doesn't look broken on paper.
Why this changes what a report is actually worth
A dashboard and a client-ready PDF report built on response quality, not just availability,
tells a genuinely different story than a standard uptime report. It can say: this device was
technically online the whole month, and here's the window where its performance degraded
anyway, and here's when it was addressed. That's a report that matches what the people using
the network actually experienced, rather than one that's technically accurate and practically
misleading.
For anyone trying to demonstrate real oversight of a network — an MSP proving value to a
client, an internal IT team justifying its budget, anyone who's ever had a stakeholder ask "so
what have you actually been watching" — that difference matters enormously. "We had no
downtime" is a claim anyone can make. "Here's exactly how every device performed, including
the parts that never went down but weren't fine either" is a claim that's much harder to fake
and much more useful to the person reading it.
What good monitoring is actually answering
The right question was never just "is it up." It's "is it actually fine, and if it isn't,
does anyone already know." Availability answers half of that, and answers it in a way that's
easy to misread as answering the whole thing. Response quality is what fills in the other
half — the slow degradation, the flapping connection, the device that's never once gone fully
offline but has quietly made someone's week worse three separate times.
None of this means uptime numbers should be thrown out — they're still a real, useful measure
of one real thing. It means they shouldn't be the only number on the page, and it means a
monitoring tool that only watches for "down" is only doing half its job, however clean the
report at the end of the month looks. NetMon was built on the assumption that the other half
is where most of the actual frustration — and most of the actual signal — has been hiding the
whole time.
That to actually ask your current tool
If you're not sure whether your existing monitoring is answering the narrow question or the
real one, there's a simple way to find out: ask it to show you a device that stayed
technically online all month but had a bad week anyway. If it can't answer that — if the only
story it can tell is uptime percentages and clean up/down timelines — it's only ever been
watching for the fire, not the wiring. That's not a criticism of the people using it. It's
usually just what the tool was built to measure, and most teams have never had a reason to
question whether "up" and "fine" were secretly two different claims all along.
The fix isn't necessarily throwing out what you have. It's asking whether response quality —
the slow, undramatic kind of degradation that never trips a simple availability check — is
being watched at all, anywhere, by anyone. For most networks, the honest answer is no, and
that gap is exactly where the next support ticket is quietly forming right now.
About the Author: Stephen Richards
Bio for Stephen Richards: Born in Colwyn Bay North Wales, Steve's introduction it Computers was at secondary school in 1974. That first year, Machine Code was hand written onto gridded paper and sent to Connah's Quay Technical College where is was copied to punch card and then entered into a mainframe computer. The results printed out were sent back for the following week!
Steve left School in 1976 joining the Royal Air Force to work on RADAR and communications equipment. His last 5 years involved working in an Automatic Test Equipment (ATE) department on the System Management Team and also writing models for Microchips. It was a good job that he had kept up with computers which had become rather a passion by the time he started in ATE.
During that time the main Mainframe we replaced in a £3.9 million upgrade reducing the run time of the biggest ATE program from just under 2 weeks to the time it took for a finger to come off a depressed return key!
Leaving the RAF after 18 years service Steve worked for a Charity (Apex Leicester Project) before returning to electronics at Sonatest in Milton Keynes which after 3 or 4 years led to a Job at Telematica the then development arm of Trafficmaster PLC (Tm). Eventually brought in-house at Tm he worked moved into the IT Support Team with his last project moving email from a Linux Box to Microsoft Echange for the 300 users in the company each of whom typically had 5 email addresses.
In 2006 Steve left to start his own company back in North Wales, Computer Technical Solutions was an MSP and moved to become an MSSP following another of Steve's passions Cybersecurity. Officially retiring in 2025, by May 2026 that overactive mind started thinking about all of the software he had seen not just for MSSPs but also for his clients that was either extremely expensive or that didn't exist with a complete answer to the needs of the SME.
By August 2026 two significant pieces of software have been created. Netmon the Network Monitoring Software and the second release Parkcore aimed at Caravan/Lodge Holiday Parks..... And so it begins!
