At P99 CONF, Chip Huyen walked through how teams cut AI inference costs without buying a single new piece of hardware. The core lesson had nothing to do with AI, really: the biggest waste in any infrastructure hides in the gap between what you think your systems are doing and what they're actually doing. You can't optimize — or even operate — what you can't see.

Every sysadmin and MSP tech living in network operations knows this pain in a very specific form: the network you manage and the network that exists are two different things. The one you manage lives in a Visio diagram from the last office move and an Excel export from a quarterly scan. The one that exists has a switch swapped in a supply closet last Tuesday, an IP camera that joined the wrong VLAN in March, and an access point nobody remembers installing.

This post is about closing that gap — why stale discovery burns hours on every incident, and how live topology mapping turns network alerts from riddles into answers.

The Outage You've Already Lived Through

You know this morning:

• 9:05 a.m. — A distribution switch drops. Users on three floors lose connectivity.
• 9:06 a.m. — The helpdesk queue starts filling: "no internet," "can't print," "Teams keeps dropping."
• 9:15 a.m. — Your standalone monitor shows 192.168.10.2 unreachable. Helpful. What's behind it? Nobody knows.
• 9:25 a.m. — Someone opens the Visio file. Last modified 2022. The switch it shows isn't the one in the rack.
• 9:40 a.m. — A tech walks to the IDF, physically checks the stack, and identifies the dead unit.
• 9:50 a.m. — Replacement begins. 40+ tickets are now in the queue, and the helpdesk has spent the morning triaging symptoms instead of working one root-cause alert.

Here's the uncomfortable part: the network knew everything within seconds. The upstream switch registered link-down on a specific port. The topology — which access switches, which APs, which printers hung off the dead unit — was sitting in the forwarding tables the whole time. No tool surfaced it, because the tools that watch the network don't hold the map, and the map that exists isn't connected to anything live.

Why Your Current Tool Stack Can't Answer "What's Connected Where?"

This isn't a people problem. It's architecture:

RMM platforms see agents, not infrastructure. ConnectWise, Ninja, and similar RMM tools are excellent at managing Windows endpoints and servers — because those have agents. Switches, firewalls, access points, printers, and IP cameras don't run your RMM agent. In most RMM consoles, your entire network layer is invisible.

Standalone network monitors see dots, not relationships. Classic monitoring tools ping an IP and graph bandwidth. They can tell you a device is down. They cannot tell you that this device is the distribution switch feeding two access switches, four wireless APs, and the entire second floor. Blast radius — the single most valuable piece of triage information — isn't in the data model.

The helpdesk sees symptoms in triplicate. One switch event generates 30–50 tickets because every affected user files their own. Each gets triaged, categorized, and responded to as if it were a separate problem. Your helpdesk metrics look catastrophic; your actual problem was one dead power supply.

Discovery was a project, not a process. Someone ran a scan before last year's audit, exported the results to a spreadsheet, and that spreadsheet has been the "network inventory" ever since. Networks drift weekly — new laptops, a contractor's switch, a smart TV in the lobby, a replacement printer nobody registered. Any discovery older than a few days is fiction.

Visio diagrams are artifacts, not data. Nothing updates them automatically. Nothing alerts off them. Nobody trusts them at 2 a.m. They document the network someone intended, not the network that exists.

The Real Cost

• Every network incident starts with 25–45 minutes of manual discovery before anyone touches the actual fix. MTTR roughly doubles — not because repairs are slow, but because diagnosis is blind.
• One event becomes 40 tickets, crushing helpdesk throughput for half a day and burying genuinely urgent, unrelated issues in the noise.
• SLA reports measure ticket response, not detection. If users report the outage before your tools do, your SLA dashboard shows green while the business sat dark for 20 minutes.
• Technicians burn out on ping-pong: "Is it us or the ISP?" "Is it the switch or the server?" Walking the floor with a laptop to trace a cable is not why anyone got into IT.

How AlertMonitor Closes the Visibility Gap

AlertMonitor treats network discovery as a continuous process, not a one-time project, and it fuses that discovery into the same platform as your monitoring, alerting, RMM, and helpdesk.

Continuous, multi-protocol discovery. AlertMonitor sweeps the network using SNMP, ARP, and active scanning — so it sees switches, firewalls, access points, printers, IP cameras, and the unmanaged endpoints nobody claims. Not just agented Windows boxes. Everything with an IP.

A live topology map, always current. The map isn't a diagram you maintain; it's a view the platform maintains. When a switch goes offline, a link drops, or a new device appears, the map updates and an alert fires instantly — with the full network picture attached.

Alerts with blast radius, not just liveness. Instead of a bare host-down ping, the alert reads: ACCESS-SW-F2 offline — 2 downstream switches, 4 APs, ~60 endpoints affected, with the topology snapshot linked. Triage starts at "which device," not "what's happening."

Change detection that catches new gear instantly. When an unknown MAC appears, AlertMonitor flags it with the IP, the vendor (via OUI lookup), and the switch port it's reachable through. You find out about the rogue device before your users find out about the IP conflict.

One console, one workflow. The network alert becomes a helpdesk ticket with topology context attached. The tech remotes into the affected server through the integrated RMM. Patch compliance is visible in the same view. Detection → triage → fix → documentation happens in one pane instead of five tabs across four tools.

Before and After

In practice, teams cut the discovery phase of a network incident from 30–45 minutes to under two, and duplicate ticket volume from a single network event drops by an order of magnitude — because the first ticket already contains the root cause.

Practical Steps You Can Take Today

You don't need to take my word for it. Start by finding out how much your current view is lying to you.

1. Sweep a subnet and see what's actually live

From a machine on the same VLAN (ARP only reflects your local segment), run this PowerShell 7+ sweep:

# PowerShell 7+ — ping-sweep a /24 so ARP entries populate, then dump what answered
$subnet = "192.168.10"

1..254 | ForEach-Object -Parallel { $ip = "$($using:subnet).$_" if (Test-Connection -ComputerName $ip -Count 1 -Quiet) { $ip } } -ThrottleLimit 64

Everything that responded is now in the local neighbor table:

Get-NetNeighbor -AddressFamily IPv4 -State Reachable,Stale | Where-Object { $.IPAddress -like "$subnet.*" -and $.LinkLayerAddress -ne "00-00-00-00-00-00" } | Select-Object IPAddress, LinkLayerAddress, InterfaceAlias | Sort-Object IPAddress

Compare the output to your inventory spreadsheet. Every row you don't recognize is a device your monitoring has never seen — and a device nobody will miss when it fails or misbehaves.

2. Ask your switches what their ports are doing

If your discovery is stale, the switch's own forwarding tables are the source of truth. With snmp installed (sudo apt install snmp on Debian/Ubuntu):

# Interface inventory + live link status for a switch (IF-MIB)
snmpwalk -v2c -c your-community-string 192.168.10.2 IF-MIB::ifDescr IF-MIB::ifOperStatus

# Trace which physical port learned a specific MAC — perfect for finding
# where that mystery printer or camera is plugged in (dot1qTpFdbPort)
snmpwalk -v2c -c your-community-string 192.168.10.2 BRIDGE-MIB::dot1qTpFdbPort | grep -i "00 1A 2B 3C 4D 5E"

That second command answers the question that consumes half your cable-tracing time: which port is this thing actually on?

3. Baseline your devices, then watch for drift

Save a known-good device list, then diff every future sweep against it:

# Save tonight's device list, then diff future sweeps against it to catch new gear
$subnet = "192.168.10"
$baseline = "C:\IT\network-baseline-192.168.10.csv"

$current = Get-NetNeighbor -AddressFamily IPv4 -State Reachable,Stale |
    Where-Object { $_.IPAddress -like "$subnet.*" -and $_.LinkLayerAddress -ne "00-00-00-00-00-00" } |
    Select-Object IPAddress, LinkLayerAddress

if (Test-Path $baseline) {
    $known   = Import-Csv $baseline
    $newGear = Compare-Object -ReferenceObject $known -DifferenceObject $current `
                 -Property IPAddress, LinkLayerAddress |
               Where-Object SideIndicator -eq "=>"

    if ($newGear) {
        Write-Host "New devices since last baseline:" -ForegroundColor Yellow
        $newGear | Format-Table IPAddress, LinkLayerAddress -AutoSize
    } else {
        Write-Host "No new devices detected." -ForegroundColor Green
    }
}

$current | Export-Csv $baseline -NoTypeInformation

This is the manual version of what AlertMonitor does continuously, across every subnet, with vendor lookup and switch-port context — but running it once will show you exactly how much drift your current process is missing.

4. Document uplinks for your three most critical switches

For each core or distribution switch, write down what's downstream: which access switches, which APs, which VLANs. That dependency list is what turns "host unreachable" into a triage plan. Then let continuous discovery keep it accurate — because the manual version goes stale the first time someone swaps a switch without telling you.

5. Wire network alerts directly into tickets — with context

In AlertMonitor, the workflow is: discovery builds the topology → alert rules watch devices and links → a fired alert auto-creates a helpdesk ticket carrying the device name, the affected downstream devices, and a map snapshot. Your helpdesk stops triaging forty symptoms and starts working one root cause.

The Takeaway

Chip Huyen's message at P99 CONF — cut costs through understanding, not procurement — applies directly to your network. Before you buy more bandwidth, another switch, or a fourth monitoring tool, get visibility into the infrastructure you already own. Most teams discover they don't have a capacity problem; they have a visibility problem, and it has been quietly inflating every outage, every SLA miss, and every 2 a.m. page.

Your network map should never be a document. It should be a live system that knows what's connected, notices the moment it changes, and tells you first.

Related Resources

AlertMonitor Network Monitoring & Visibility AlertMonitor Platform Overview Book a Demo Network Monitoring & Visibility Resources