The Network Problem You Never Heard About (Because We Already Fixed It)
Think about the last time you found out something was wrong with your network. Chances are
it wasn't a dashboard that told you. It was a person — a customer whose VOIP calls kept
dropping, a receptionist whose printer had gone dark for the third time that week, an office
manager who'd been quietly annoyed for two days before finally sending the email. By the time
the problem reaches you, it's already cost someone their afternoon, and it's already cost you
the chance to look like you were on top of it.
That's the version of IT support most people have simply learned to expect. Something breaks,
someone notices, someone complains, someone fixes it. It's so normal that "we're looking into
it" barely registers as an apology anymore — it's just the shape customer service takes. We
think that's a shame, because it's also completely unnecessary, and it's the whole reason
NetMon exists.
The fire alarm problem
Most monitoring tools are built like fire alarms. They sit quietly until something's
unambiguously wrong — a device stops responding, a service goes dark — and then they make
noise. That's better than nothing. But a fire alarm only tells you about the fire. It says
nothing about the exposed wiring, the frayed cable, the space heater running too close to the
curtains — the stuff that was going wrong long before anything caught fire, and that a
genuinely attentive person would have caught first.
Networks degrade the same way. A NAS drive doesn't usually go from perfectly healthy to
completely dead in one step. It flickers first — packet loss creeping up, response times
getting worse, small drops that don't trip a simple "is it up" check but that anyone using it
would absolutely notice. A router doesn't normally vanish without warning either; more often
it strains under load for days before it finally gives up. All of that is visible, if
something is actually watching for it. Most tools aren't. They're watching for the fire, not
the wiring.
What "already caught this" actually looks like
NetMon auto-discovers everything on a network the moment you point it there — routers,
switches, NAS drives, printers, VOIP phones, workstations, the IoT odds and ends nobody
remembers plugging in — and it doesn't stop at "online" or "offline." It tracks response
quality: latency, packet loss, the slow creep of degradation that's the actual early-warning
signal for most real-world failures. A device that's technically reachable but dropping a
third of its packets isn't fine, and NetMon doesn't pretend it is.
Here's the part that actually changes the support conversation, though. When a genuinely
important issue shows up — a rogue, unrecognised device appearing on a network that's
supposed to be locked down, a NAS or VOIP phone or printer or router whose response quality
drops out of the green, a printer or router actually going dark — NetMon doesn't just log it
quietly and wait for someone to check the dashboard. It raises a support ticket automatically,
in the right queue, before anyone has had to notice, let alone complain. The technician's
first interaction with the problem isn't a phone call asking what's wrong. It's a ticket that
already says what's wrong, on what device, and since when.
Device offline alerts are handled a little differently, deliberately. An email goes out, and
that's usually the right amount of noise — most outages are brief, and flooding a ticket
queue with things that resolve themselves in ninety seconds helps nobody. The line NetMon
draws is specific: things that need a human's judgement get a ticket, automatically; things
that mostly resolve on their own get a quieter nudge. That's not a technical detail. It's a
philosophy about what a monitoring tool owes the people using it — enough signal to act on,
not so much noise that the real signal gets lost in it.
Why this is a trust problem, not a features problem
There's a particular kind of relief in hearing "we already caught this" instead of "let me
look into that." The first sentence tells you someone was paying attention before you had to
ask. The second tells you they weren't, until you did. Customers can feel that difference
even when they can't articulate it, and it's the single biggest lever an MSP or IT team has
over how trustworthy they seem — not the tools they use, not the SLA they promise, but
whether the first thing a customer hears about a problem is a question or an answer.
Most support tooling optimises for how fast you can respond once something's reported. That's
useful, but it accepts the premise that being reported to is how problems start. NetMon is
built around a different premise: that the best response time is the one that happens before
the report exists at all. You can't out-respond a fire once the smoke's in the room. You can,
with the right monitoring, make sure there's no fire by the time anyone would have smelled
smoke.
What this actually means day to day
In practice, this shows up as a quieter, less dramatic version of IT support than most people
are used to. Fewer angry calls, because fewer problems get the chance to become the kind of
thing someone gets angry about. Fewer 2am pages for things that could have been caught during
the day. A ticket queue that reflects real, current problems instead of a mix of urgent issues
and stale "still waiting to hear back" threads, because tickets that come from monitoring
arrive with context already attached — what device, what metric, what threshold, when it
started.
It also means the story an MSP can tell a client changes shape. Instead of "we responded
quickly when things broke," it becomes "here's what we caught before it became a problem you
noticed" — a genuinely different, genuinely more valuable claim, and one that's much harder
for a competitor without proactive monitoring to make convincingly.
None of this requires customers to do anything differently. They don't need to know NetMon
exists, don't need to check a dashboard, don't need to change how they report problems. The
entire value is in the problems they never end up reporting, because someone already knew.
That's a strange thing to build a product around — success that's invisible by definition —
but it's the only kind of proactive support that actually holds up under scrutiny. Not "we're
fast." Just: we were already there.
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!
