The Register's report that former Labour deputy leader Tom Watson has joined Palantir as UK senior vice president — arriving, awkwardly, just as the firm's £330M NHS contract "nears break point" — is being read as a politics story. Palantir insists its new hire is there to "build things, not to open doors." Fine. But strip out the Westminster angle and there's a lesson sitting there for every sysadmin, IT manager, and MSP tech reading this: an organization can spend £330M on a platform and still be unable to answer the most basic operational question — what is actually on our network, right now?
You don't need a nine-figure contract to hit the same wall. You need about 200 endpoints, two people in IT, and six months of "we'll update the documentation later."
The Question That Exposes Everything
Ask yourself honestly: if your CIO walked in today and asked for a complete, accurate inventory of every device on the network — switches, firewalls, access points, printers, IP cameras, that one laptop in marketing nobody has ever imaged — where would you get it?
- A Visio diagram last touched in 2022?
- An Excel export from a quarterly scan that ran while half the warehouse was on holiday?
- The asset database your helpdesk tool maintains, which only knows about machines with the agent installed?
For most teams the honest answer is "some combination of the above, and none of it is current." That's not a documentation failure. It's an architecture failure — and it's the same failure mode that turns nine-figure government contracts into "break point" headlines. The platform on top can be world-class; if the ground truth underneath was never unified, the whole thing strains the first time someone asks a hard question.
The Problem in Depth: Stale Maps, Blind Alerts, Fragmented Truth
Most discovery is a snapshot, not a state. Legacy NMS platforms and standalone scanners run on a schedule — nightly, weekly, monthly. The moment a tech plugs an unmanaged switch under a desk, an estates team adds IP cameras, or someone brings a consumer NAS from home, your "map" is wrong. And unlike a failed backup, a wrong map fails silently. You find out when it hurts.
Alerts arrive without context. Your monitoring tool pings "10.14.8.2 unreachable." Is that a printer or the host running the finance ERP? Which switch is it on? Which 30 other devices dropped at the same time? In most stacks — a legacy SNMP monitor here, a separate RMM there, a helpdesk that has never seen either — the alert is a dead-end IP address. So the tech opens a browser tab, tries a reverse lookup, greps the inventory spreadsheet, and when that fails, walks to the comms room to read labels off a patch panel. That's how a 5-minute fix becomes a 45-minute incident.
Every integration is a project. Siloed tools weren't designed to share a single model of the network, so making them talk costs professional-services hours — or a script somebody has to babysit. Multiply that across a national health service with hundreds of trusts and sites, and you get exactly the situation where a flagship contract reaches a break point: too many systems, no shared truth, every question requiring a human to stitch answers together.
The real-world bill, which you're already paying:
- Users report outages before your tools do. The "is the Wi-Fi down?" message lands 15 minutes before any alert, because nobody was polling the switch those users hang off.
- MTTR is dominated by identification, not repair. Finding the affected switch takes ten times longer than replacing it.
- Change windows break because a "spare" port was feeding a card printer nobody documented.
- Audits and renewals hurt. Asset inventories that don't match reality mean failed attestations and scope-creep conversations with vendors.
- Morale bleeds out. Your most senior techs spend their afternoons doing network archaeology with a label maker and a hope.
One scenario every IT pro will recognize: an unmanaged switch in a meeting room bridges two VLANs and triggers a loop. STP reconverges; 40 users drop. Your monitoring shows a scatter of individual endpoint alerts, your helpdesk shows 14 tickets, and nobody can see the common ancestor — because no tool in the stack holds a live map of which switch those endpoints actually hang from.
How AlertMonitor Solves This: A Live Map That Is the Monitoring
AlertMonitor's network visibility isn't a scheduled scan bolted onto a dashboard. Discovery runs continuously — SNMP, ARP, and active scanning — so the topology map reflects the network as it is now, not as it was at 2am last Sunday.
Concretely, what changes:
- Every device type gets discovered, not just servers with agents. Switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints appear on the map automatically.
- Link-level topology updates in real time. When a switch goes offline, AlertMonitor knows exactly which devices and links hung off it — the alert reads "SW-FLOOR3-02 offline: 34 endpoints across the Sales and VoIP VLANs affected, last seen 04:12," not a naked IP address.
- New devices trigger alerts with full context. An unknown MAC appears on port Gi1/0/14 of a core switch, and you get an alert with the switch, port, VLAN, and vendor OUI. That's your rogue switch, your shadow NAS, your contractor's laptop — caught in minutes, not at the next quarterly audit.
- One console from alert to fix. Because monitoring, RMM, helpdesk, and patching share one platform, an alert becomes a ticket with the topology context attached, and the tech remotes straight into the affected endpoint. No tab-hopping across five tools to support one incident.
The old workflow: monitoring pings an IP → tech greps a spreadsheet → nothing → walks to the comms room → traces the patch panel → finds the dead switch 40 minutes later → updates the Visio diagram (maybe).
The AlertMonitor workflow: alert fires with device, location, downstream impact, and link status → tech reads the payload in 30 seconds → remote session or dispatch with the right port and patch in hand → ticket auto-updated → map already reflects the replacement.
That's the difference between a 45-minute identification phase and a 90-second one. Across a year and hundreds of incidents, it's the difference between a team that firefight and a team that runs.
Practical Steps: Find Your Blind Spots Today
Before buying anything, find out how wrong your current picture actually is. Three things you can do in the next hour:
1. Snapshot your ARP tables and compare against your inventory.
# Export current IPv4 neighbors (ARP) from a Windows host as an inventory cross-check
Get-NetNeighbor -AddressFamily IPv4 |
Where-Object { $_.State -in 'Permanent','Reachable','Stale' } |
Select-Object IPAddress, LinkLayerAddress, InterfaceAlias, State |
Export-Csv -Path 'C:\Temp\arp-snapshot.csv' -NoTypeInformation
Run this per subnet and diff it against your asset spreadsheet. Every MAC in the ARP table that isn't in your inventory is a device your documentation has never heard of — printers, cameras, AV gear, the lot.
2. Schedule the diff so new devices surface automatically.
# Detect devices that appeared since the last scan and log them
$baseline = Import-Csv 'C:\Temp\arp-baseline.csv'
$current = Get-NetNeighbor -AddressFamily IPv4 |
Where-Object { $_.State -in 'Permanent','Reachable','Stale' } |
Select-Object IPAddress, LinkLayerAddress, InterfaceAlias
$newDevices = Compare-Object -ReferenceObject $baseline `
-DifferenceObject $current -Property IPAddress, LinkLayerAddress |
Where-Object { $_.SideIndicator -eq '=>' }
if ($newDevices) {
$file = "C:\Temp\new-devices-$(Get-Date -Format yyyyMMdd-HHmm).csv"
$newDevices | Export-Csv -Path $file -NoTypeInformation
Write-Output "$($newDevices.Count) new device(s) detected: $file"
}
$current | Export-Csv -Path 'C:\Temp\arp-baseline.csv' -NoTypeInformation
Wire that into a scheduled task. It's the poor man's continuous discovery — and within about two days you'll understand exactly why AlertMonitor treats this as a first-class, always-on feature instead of a batch job.
3. Verify SNMP is actually answering on your switches. Continuous discovery and live topology depend on working SNMP. A surprising share of "our map is always stale" complaints trace back to one switch where the community string was changed during a hardening project and never updated anywhere.
# Confirm the switch answers SNMP and reports what it is
snmpwalk -v2c -c <community> 10.10.0.2 SNMPv2-MIB::sysDescr.0
(Use SNMPv3 in production — v2c with a default community string is its own conversation.)
Then get ground truth on cabling straight from the switch itself:
# On the switch: what is actually plugged into each port, per LLDP
show lldp neighbors detail
If what LLDP shows differs from your diagram, your diagram is the problem.
4. Then stop doing this by hand. The scripts above prove the point; they don't scale to 40 clients or a multi-site estate. That's the job AlertMonitor's network visibility does continuously: discovery via SNMP, ARP, and active scanning, a topology map that updates the moment the network changes, and alerts that arrive with the context that used to cost you an hour of floor-walking. The NHS-sized version of this lesson is the same as the 200-seat version: platforms don't fix ground truth. Continuous visibility does.
Related Resources
AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.