NetMon

A mixed estate: a few devices fully instrumented, most of them answering SNMP and little else, and a stubborn remainder — power units, cameras, sensors, appliances somebody installed years ago — that answer a ping and nothing more. What a network team actually needs to know is whether all of it is up, how each part of it has behaved over the past week, and what changed shortly before the complaint arrived.

Why I built it

Because a diagnosis needed an instrument that did not exist. I was trying to establish whether a link had been flapping overnight or whether a handful of devices had been unreachable for a few minutes at a time all week, and the tools to hand either could not see those devices at all or could tell me the state now and nothing about the state yesterday.

Commercial monitoring platforms are either too large for a single network team or too shallow to be useful once you need per-device detail. They are not badly built; they answer a different question — an estate-wide, reportable, management-facing question — and the question in front of me was a diagnostic one about specific devices on a specific afternoon. Vendor tools stop exactly where your problem starts, and that is the point at which I write the missing piece rather than work around it. NetMon is a monitoring application because a fault needed measuring, not because I wanted to write a monitoring application.

The problem

Devices that expose nothing get quietly left out of the inventory, and they are disproportionately the ones that fail without telling anybody. An estate where part of the equipment is invisible is not being monitored; it is being sampled, and the gaps are exactly where the surprises live.

The second gap is history. Most tools will tell you the state now, which is the one thing a user has usually already told you. A fault that comes and goes leaves no trace, so an intermittent problem gets argued about rather than diagnosed, and the argument tends to be settled by whoever is most senior rather than whoever is right. The third is separation: a management network, a client estate and a bench sharing one view is how you end up reading the wrong graph confidently. All of that costs the same three things — outages found by users, intermittent faults that stay open for weeks, and a monitoring scope decided by per-device licensing rather than by engineering.

What I did

• Reachability first, and ping-only devices treated as first-class. Continuous reachability and latency monitoring across the estate, including the devices that expose nothing else, because an inventory that only contains the cooperative equipment is the wrong inventory.
• Per-device history and charting, with export. The deliverable is often evidence handed to a vendor, a change board or a client, so the history has to leave the tool in a form somebody else will accept.
• Multiple monitoring instances. Separate networks stay separate, deliberately, rather than being merged into one pane that flatters the dashboard and misleads the engineer.
• Local storage, no cloud dependency, no per-device licensing. A tool that needs a working network to report on that network is the wrong shape, and what gets monitored should be an engineering decision rather than a budget one.
• A packet-capture hook for the moment counters stop being enough. Reachability data answers whether; it does not answer why. Rather than pretend otherwise, the tool hands over to capture at that boundary.
• Honest about what it can and cannot see. A device that only answers a ping is presented as exactly that, because a monitoring tool that overstates its coverage is worse than one with gaps you know about.

The result

The state of an estate at a glance, and the detail behind it without opening four other tools. The equipment that used to be invisible now appears alongside everything else, an intermittent fault becomes a chart instead of a disagreement, and the awkward question — was it doing this last week as well — has an answer that can be exported and sent.

It is also quick to deploy and cheap to abandon: no server component, no cloud account, nothing that has to be justified before a device can be watched. And it is evidence of how I prefer to work. The code exists only because a diagnosis needed an instrument; if a product had answered the question, I would have bought it and got on with the fault.

Requirements

Windows, with an installer that sets NetMon up as a service. Linux on x64 and ARM64, and macOS on Apple silicon and Intel, from the archives above, each with a script that does the same. The .NET runtime travels inside every download, so nothing else has to be installed first. NetMon keeps its data in a local database file — no external database, no cloud account — and is used from a web browser.