Last week, Amazon CEO Andy Jassy predicted that the frontier AI race won't produce a single winner. Six to eight models, he argued, will end up “good enough” for almost everything, and enterprises will run several of them side by side. The tech press spent the week arguing about which models survive.
Here's what nobody in that debate mentioned: while vendors fight over model counts, your network is quietly absorbing the fallout of AI adoption. A GPU server racked for an internal pilot. An inference appliance a vendor left behind. IP cameras facilities installed without telling anyone. Smart displays in the meeting rooms. A demo laptop plugged into a conference room port. An eight-port unmanaged switch somebody bought on their own because they “needed one more jack.” Every one of these lands on infrastructure you are accountable for — and most IT teams still discover what's on their network through user complaints, quarterly scans, or a Visio diagram last touched during the last office move.
If you're the sysadmin who got paged at 2am because nobody noticed a disk filling up until Exchange stopped, or the MSP tech with twelve browser tabs across five tools just to triage one client's “the internet is slow” ticket, this post is for you.
The Problem: Your Tools See Fragments, Not a Network
The AI model debate is a useful mirror for what's wrong with most IT monitoring stacks: everyone is betting on a winner while the environment keeps multiplying underneath them. You don't have one tool anymore — you have four or five, each holding a partial, stale copy of the truth.
What your current stack actually sees
- Your RMM agent (NinjaOne, ConnectWise RMM, N-able, Datto — pick one) only sees devices it's installed on. The unmanaged switch under the desk, the IP camera, the printer with a static IP conflict, the rogue DHCP responder — invisible. An agent-based tool is structurally blind to anything without an agent.
- Your standalone SNMP monitor (PRTG, SolarWinds, LibreNMS) polls on an interval — typically one to five minutes — and only alerts on devices it already knows about. Discovery usually runs nightly or weekly, so the map reflects last night's network, not this morning's.
- Your topology documentation is a Visio file on a file share, or an expensive automated mapper whose discovery runs quarterly. Either way, it's a photograph of the past.
- Your helpdesk receives a ticket that says “Wi-Fi is down on floor 2” with zero device context attached. The tech has to cross-reference the monitor, the RMM, and maybe the firewall console before they even know where to start looking.
None of these systems share a device model. The switch exists in the SNMP tool, the laptop exists in the RMM, the ticket exists in the helpdesk — and the actual cable between core switch port 24 and the floor-2 access switch exists only in someone's head.
Why the gaps exist
Siloed architecture, plain and simple. Each tool was bought separately, evaluated separately, and deployed with its own database, its own inventory, and its own alert engine. Legacy design assumptions made it worse: discovery used to be expensive, so vendors built scheduled scans instead of continuous discovery. RMM platforms assumed agent coverage equals environment coverage, which was never true on the network layer. And helpdesks were built to track human conversations, not infrastructure state. The gaps aren't a configuration mistake on your part — they're baked into how these tools were designed.
What it actually costs: a Tuesday morning
9:47 AM. An uplink port starts flapping on the floor-2 access switch. Maybe the cable got knocked, maybe an SFP is dying.
If that switch is in your SNMP monitor and your polling interval is five minutes, an alert might fire — assuming the flap survives whatever threshold suppression is configured. If someone added that switch three weeks ago and nobody updated monitoring, nothing fires at all.
9:58 AM. First ticket: “Teams keeps dropping.” 10:05 AM. Seven more tickets, all phrased differently: “internet slow,” “can't print,” “Outlook disconnected.” The tech on duty starts where every ticket points nowhere: ping the gateway (fine), ping 8.8.8.8 from the server VLAN (fine), restart the wireless controller, open a case with the ISP. 10:40 AM. Someone physically walks to the wiring closet, watches the uplink light blink amber, and swaps the patch cable.
Fifty-three minutes. Forty people affected. Fourteen tickets to close. And the lasting damage isn't the downtime — it's that the entire floor now believes IT finds out about problems last. Multiply that across a month, or across 30 MSP clients, and you get the real costs: SLA breaches you can't even prove, because detection timestamps live in the monitor and response timestamps live in the helpdesk and the two never reconcile. Techs doing cable archaeology instead of actual engineering. The quiet burnout of a team that is permanently reactive.
And the flapping uplink is the good scenario, because at least the device existed in monitoring. The worse one: a misconfigured device starts answering DHCP requests on a VLAN, half a floor gets 192.168.99.x addresses, and the symptoms read as “Wi-Fi is flaky sometimes” for two weeks — while your dashboards show every known device as green. Your tools weren't lying. They just couldn't see the thing causing the problem.
How AlertMonitor Solves This
AlertMonitor starts from a different assumption: the network is the inventory, and the inventory changes constantly — especially now, when AI pilots, IoT devices, and shadow IT are adding endpoints faster than any quarterly scan can catch them.
- Continuous discovery via SNMP, ARP, and active scanning. Switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints are found as they appear — not at the next scheduled scan. When a new MAC address shows up on switch port 14, an alert fires: new device, which port, which switch, first-seen time.
- A live topology map that reflects the real network state right now. Links, dependencies, and status are current. You stop maintaining a second, manual version of the truth in Visio, and you stop arguing about whose diagram is correct.
- Alerts with full network context. When a switch goes offline or a link drops, the alert names the device, its position in the topology, and what's downstream of it. You know the impact radius before you finish reading the alert.
The workflow, then vs. now
The old way: user ticket arrives → open the monitor and search for the site → open the RMM to check managed devices → log into the firewall UI → ping and traceroute from three angles → eventually walk to the closet.
The AlertMonitor way: alert at 9:47 — “Link flap detected: Core-SW1 Gi1/0/24 → Floor2-Access-SW” — with the topology already showing the 38 endpoints downstream. One click converts the alert into a helpdesk ticket with the device record and affected hosts attached. If the downstream devices are managed, you jump straight into a remote session from the same record. When the link stabilizes, the ticket timeline already contains detection and resolution data.
Because monitoring, RMM, helpdesk, and patching all operate on the same inventory in AlertMonitor, the alert links to the device, the device links to its tickets and patch state, and the SLA report reconciles detection time against response time without a spreadsheet in between. For MSPs, every client's network map lives on the same NOC dashboard — no per-client tool logins just to triage one flapping port.
The time math is straightforward: detection drops from user-reported ~25 minutes to seconds. Triage shrinks because you're no longer narrowing down “whose fault is it” — the topology tells you. And the rogue DHCP scenario collapses from two weeks of “flaky Wi-Fi” to minutes, because the new-device alert fires when the device appears, not when users get angry enough to escalate.
Practical Steps You Can Take Today
Before you change anything, measure your current blindness. These four checks take under thirty minutes and will tell you exactly how much of your network your existing stack can't see.
1. Pull the live ARP table from a machine on each subnet and export it.
# Snapshot every device this machine recently talked to on its local subnet
Get-NetNeighbor -State Reachable,Stale,Permanent |
Where-Object { $_.LinkLayerAddress -and
$_.IPAddress -notlike '127.*' -and
$_.IPAddress -notlike '169.254.*' -and
$_.IPAddress -notlike '224.*' } |
Select-Object IPAddress, LinkLayerAddress, State |
Sort-Object IPAddress |
Export-Csv -Path 'C:/Temp/live-devices.csv' -NoTypeInformation
2. Compare that against your documented inventory to surface unknown devices.
$documented = Import-Csv 'C:/Temp/documented-inventory.csv'
$live = Import-Csv 'C:/Temp/live-devices.csv'
$knownMACs = $documented.MAC.ToLower()
$unknown = $live | Where-Object { $knownMACs -notcontains $_.LinkLayerAddress.ToLower() }
$unknown | Format-Table IPAddress, LinkLayerAddress -AutoSize
Every MAC in $unknown is a device your monitoring either doesn't know about or knows by a name nobody recognizes. That list is your blind spot — on one subnet, as of right now.
3. Check for rogue DHCP responders on the subnet.
# Anything answering on UDP 67 that is not your DHCP server is a bad afternoon waiting to happen
nmap -sU -p 67 --open 192.168.1.0/24
4. Poll interface state on your switches directly and compare to your dashboard.
# Up/down state of every interface on a switch
snmpwalk -v2c -c 'your-community' 192.168.1.2 IF-MIB::ifOperStatus
If this output disagrees with what your monitoring tool shows, you've just measured your discovery lag.
5. Turn on the alerts that catch these scenarios automatically. In AlertMonitor, that means: new-device alerts per switch port, alerting on link state changes and flapping (not just device-down), and automatic alert-to-ticket creation for network alerts so detection and response timestamps land in the same record.
The scripts above are a one-time sanity check. AlertMonitor runs that same comparison continuously, across every subnet, switch, and client — which is the entire point. Andy Jassy's prediction is about picking the right model for each job instead of betting on one. The operations version of that lesson: stop betting on a stack where four tools each hold a fragment of the truth. Your network already knows what's connected. The only question is whether your tools do.
Related Resources
AlertMonitor Network Monitoring & Visibility
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.