Nobody Could Name All 600 Million Records. Can You Name Every Device on Your Network?

When Spirit Airlines filed for bankruptcy protection, the most interesting asset on the table turned out not to be gates, routes, or brand equity — it was data. Micro1 has offered $12.5 million for roughly 600 million email and chat records generated by 17,000 employees, 17 million OneDrive files, 20.5 million SharePoint items, and more than 30 million recorded customer service calls. Google made its own bid weeks earlier. The bidders aren't fighting over airplanes. They're fighting over a complete record of how an organization actually ran.

Here's the uncomfortable parallel for those of us in IT: nobody inside Spirit could have enumerated that trove. Decades of emails, chats, files, and calls accumulated everywhere and nowhere, with no one holding the full picture — until the company stopped, and outsiders had to bid for the privilege of reconstructing it.

Now hold that thought up to your own environment. Not the network in the Visio diagram from 2021 — the real one. The one with an unmanaged switch daisy-chained under a conference room table, an IP camera subnet a facilities vendor stood up "temporarily" in 2022, a print server on a tower under a desk in accounting, and whatever that device at 192.168.10.217 is. If your senior network admin resigned tomorrow, could anyone on the team reconstruct what's actually out there?

If the honest answer is no, you have a Spirit Airlines problem — and it's costing you hours on every single outage.

The 2 a.m. Version of This Problem

Every on-call tech knows this page. At 2:07 a.m., the phone erupts — not with one alert, but with seventeen. The dashboard shows 17 hosts "down" at the branch office. Which one is the cause? Which are symptoms? You remote into the branch router, run a traceroute, SSH into whatever switch will answer, and start dumping MAC tables one console session at a time. The Visio diagram is three reorgs out of date, and the person who actually knew that wiring closet left the company in 2023.

Forty minutes later, you've isolated it: the uplink port on the branch switch went bad. The fix takes ninety seconds. The other thirty-eight minutes were archaeology — manually rebuilding a topology map that should have existed, current, inside your monitoring platform.

That gap — between time-to-understand and time-to-fix — is where most outage pain actually lives. And it exists because your tools see the network the way your documentation does: statically, incompletely, and months behind reality.

Why Your Current Tooling Can't See the Whole Network

Agent-based RMM platforms are blind to anything without an agent. Ninja, ConnectWise, Datto, Kaseya — these tools are excellent at managing endpoints, but they only know devices where someone installed software. Unmanaged switches don't run agents. Printers don't run agents. IP cameras, HVAC controllers, door access panels, conference room displays, the vendor's laptop plugged into your drop — all invisible. Your RMM inventory says 97 managed devices. The DHCP scope says 143 things are getting addresses. Nobody can account for the 46-device difference.

Standalone network monitors only know what you told them. Legacy NMS tools poll the devices someone manually added, usually during implementation. Add a switch in March and forget to add it to monitoring, and it's a ghost until something breaks. Quarterly discovery scans mean you operate with up to 90-day blind spots in environments where ports get repatched and gear gets swapped every month.

Documentation decays the moment it's finished. The wiki was accurate the day it was written. The Visio file was accurate the day before the office refresh. Networks drift constantly — and static documentation has no mechanism to keep up.

And none of these systems talk to each other. The RMM has one asset database, the network monitor has another, the helpdesk has a third, and the "real" documentation lives in a spreadsheet nobody owns. When a link drops, the monitor fires 14 host-down alerts with no context. The helpdesk sees 14 tickets and can't tell one incident from fourteen. Nobody can answer the only question that matters: what actually failed, and what's affected?

What the Visibility Gap Actually Costs

Concrete scenario: a mid-size company, 12 branches, one core datacenter. A failing uplink takes Branch 7 offline at 2:07 a.m.

• 2:07 a.m. — 17 host-down alerts fire. The on-call tech gets paged.
• 2:15 a.m. — Tech remotes in, runs a traceroute, hunts for the branch switch. It isn't on the diagram.
• 2:40 a.m. — After manually dumping ARP and MAC tables from the branch router, the dead uplink port is identified.
• 2:41 a.m. — Port reset. Network restored.
• 7:30 a.m. — Helpdesk opens 23 tickets from Branch 7 users anyway, because nothing links them to the incident that was already resolved.

That's roughly 35 minutes of triage for a 90-second fix, plus a morning of redundant ticket handling. Multiply it by every "the network is slow" mystery, every audit request for a current network diagram, and the gap isn't an inconvenience — it's a standing tax on your team.

MSPs feel this hardest at onboarding. You sign a client, ask for network documentation, and receive a Visio file from 2019 that matches reality in no meaningful way. Your first two weeks on the account are archaeology: which switch feeds which floor, and which "temporary" devices became load-bearing infrastructure three years ago.

Then there's the quieter cost: bus factor. When topology knowledge lives in one admin's head instead of a live map, every vacation and resignation is a mini-crisis. Spirit's data trove had the same pathology — decades of accumulated truth with no index and no live picture.

How AlertMonitor Closes the Gap

Continuous multi-protocol discovery, not quarterly scans. AlertMonitor continuously discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — using SNMP, ARP, and active scanning. Devices that can't run agents get discovered anyway. Those 46 unaccounted devices in your DHCP scope land on the map, named and placed, within the first discovery cycle.

A live topology map that reflects the network right now. Not a diagram you maintain — a map the platform maintains for you. When a switch goes offline, a link drops, or a new device appears, the map updates and an alert fires instantly with full network context.

Alerts with context instead of alert storms. When the Branch 7 uplink fails, AlertMonitor doesn't fire 17 host-down alerts. It fires one: link down on a specific port, here's everything downstream, here's the network context. Time-to-understand collapses from 35 minutes of archaeology to seconds of reading.

New-device alerts kill shadow IT blindness. A vendor laptop, a rogue access point, an IP camera nobody requested — you get an alert the moment it appears, not at the next quarterly scan.

The workflow changes completely:

And because it's one platform, context flows: the discovered device is a managed asset, the alert can open a helpdesk ticket pre-loaded with topology context, and patch status, monitoring history, and ticket history live on the same record. The IT manager finally produces an SLA report that answers "which incident, on which link, resolved in how long" — without exporting CSVs from three systems and reconciling timestamps by hand.

Practical Steps: Find Your Ghost Devices Today

Step 1 — Quantify your blind spot. Compare DHCP leases against your RMM inventory:

# Compare DHCP leases against your RMM inventory to find unmanaged devices
$dhcpLeases = Get-DhcpServerv4Lease -ScopeId 192.168.10.0 |
    Where-Object { $_.AddressState -eq "Active" }

$inventory = Import-Csv "C:\Reports\rmm-agent-inventory.csv"   # columns: Hostname,MAC
$knownMACs = ($inventory.MAC -replace "-", ":").ToLower()

$unknown = $dhcpLeases | Where-Object {
    ($_.ClientId -replace "-", ":").ToLower() -notin $knownMACs
}

$unknown | Select-Object IPAddress, HostName, ClientId |
    Export-Csv "C:\Reports\unmanaged-devices.csv" -NoTypeInformation
"Devices in DHCP scope: $($dhcpLeases.Count) | RMM-managed: $($inventory.Count) | Unaccounted: $($unknown.Count)"

Step 2 — Sweep a subnet and read live ARP. See what's actually answering on a VLAN right now:

# Ping-sweep a subnet, then list live neighbors from the local ARP cache
1..254 | ForEach-Object -Parallel {
    $ip = "192.168.10.$_"
    if (Test-Connection -ComputerName $ip -Count 1 -Quiet) { $ip }
} -ThrottleLimit 64 | Out-Null

Get-NetNeighbor -AddressFamily IPv4 |
    Where-Object { $_.IPAddress -like "192.168.10.*" -and $_.State -ne "Unreachable" } |
    Sort-Object IPAddress |
    Format-Table IPAddress, LinkLayerAddress, State -AutoSize

Step 3 — Get the truth from the switch itself. The MAC address table is the only source that knows what's physically plugged in:

# Every device the switch has actually seen — VLAN, MAC, and physical port
ssh admin@branch-sw01 "show mac address-table" \
  | awk '$1 ~ /^[0-9]+$/ {print $1, $2, $4}' \
  | sort -u

And check how stale your "managed" infrastructure really is:

# How long has this switch been up, and when did its running config last change?
snmpget -v2c -c YourCommunityString 192.168.10.2 sysUpTime.0
snmpget -v2c -c YourCommunityString 192.168.10.2 .1.3.6.1.4.1.9.9.43.1.1.2.0

If that config-change timestamp is years old, nobody has looked at this device in years — which means nobody knows what's hanging off it.

Step 4 — Stop sweeping manually. This works once. It doesn't work continuously, and it doesn't page anyone at 2 a.m. In AlertMonitor:

1. Point discovery at your gateways and core switches with SNMP credentials — ARP and active scanning handle the rest.
2. The first discovery cycle builds the live topology map automatically.
3. Enable alerts for link state, device offline, and new device on network.
4. Connect alerts to the helpdesk so tickets arrive with topology context already attached.
5. MSPs: run this on day one of every new client. You get a real map in hours instead of two weeks of interviews and stale Visio files.

The Takeaway

The bidders fighting over Spirit's data are paying $12.5 million for completeness — a record nobody maintained, but that captured everything anyway. You don't need to bid for that on your own network. You need discovery that runs continuously and a map that's never out of date. The difference between archaeology and answers is whether that picture was built before the outage or during it.

Related Resources

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