P99 CONF 2026 ran October 21–22, and The New Stack's recap of five database talks lands on one theme: every database decision is a trade-off. Consistency versus availability. Durability versus latency. Flexibility versus raw speed. The engineers on those virtual stages count microseconds, because at their scale the slowest one percent of requests — the p99 — is what users actually feel.
For those of us running infrastructure instead of designing database engines, there is an uncomfortable parallel. We make trade-offs every day too, and the most expensive one never gets a conference talk: we trade live network visibility for stale tooling and static documentation. The result is the operational equivalent of a p99 spike — rare, unpredictable events like a flapping uplink, a rogue device, or a degraded path that consume a wildly disproportionate share of your team's time and define IT's reputation with the business.
You can tune a database to sub-millisecond reads. It will not help if a 48-port switch in a wiring closet starts flapping its uplink and nobody can tell you which closet, which floor, or which client it belongs to.
The Problem: Your Monitoring Stack Is a Set of Unwritten Trade-Offs
Your RMM sees agents, not switch ports
Most RMM platforms — NinjaOne, ConnectWise, Syncro, Datto — grew up around endpoint agents. They are excellent at telling you a Windows Server's C: drive is at 91 percent or that a service stopped. They are structurally blind to the network, because they only see what the agent sees: the NIC of the machine it lives on. A link that drops for 40 seconds twice an hour never crosses a 5- or 15-minute polling window. The agent keeps reporting green. Meanwhile users experience it as "Teams keeps cutting out," and the helpdesk collects a dozen disconnected tickets over two weeks before anyone thinks to check a switch port.
Your standalone network monitor sees devices, not tickets
Plenty of shops bolt on PRTG, SolarWinds, or LibreNMS for SNMP polling. That closes part of the gap: interface states, bandwidth, uptime. But the alert lands in an email mailbox or a separate mobile app, while the user-facing tickets land in the helpdesk. Nothing joins them. The tech troubleshooting "the CRM is slow" has no way to see that one hop upstream, port Gi1/0/24 on the floor switch has been logging CRC errors since Thursday. So they do what their tooling forces them to do: eyeball timestamps across three consoles, restart the app server for good measure, or escalate to the network vendor "just to check the firewall." Forty-five minutes gone, root cause untouched.
Your network map is a historical document
Ask a room of sysadmins when their topology diagram was last accurate and you will get laughs. The Visio file is from 2019. The IP allocation spreadsheet lives in one person's OneDrive. Discovery scans run quarterly at best, so anything installed after the last scan is invisible — the IP camera the facilities vendor hung in the warehouse, the consumer 8-port switch daisy-chained under a desk in accounting, the old access point someone never decommissioned. These are precisely the devices that cause DHCP scope exhaustion, IP conflicts, and broadcast storms. You cannot monitor what you have never discovered.
What this actually costs
The gaps are not abstract. They show up in specific, recurring ways:
- A flapping uplink at a branch office surfaces as 15–25 helpdesk tickets over two weeks, each triaged as an isolated "slowness" issue by two or three different techs before anyone correlates them.
- An unknown device acting as a rogue DHCP server can take a 40-person office down for half a day while the ticket stream says "Wi-Fi down" and the wireless controller insists every AP is green.
- A 2 a.m. page reading only "Device Down: SW-BRANCH-02" costs 30–60 minutes of VPN-and-poke triage, because the alert answers nothing: Is the switch dead or its uplink? What runs through it? Is it the one nobody has touched since 2021?
Why do these gaps exist? Not because any one tool is broken. RMMs, helpdesks, and SNMP monitors were built in different eras, for different buyers, and several live under the same logo only because of acquisitions. The integration nobody shipped becomes manual work, and the manual work lands on your team. Nothing burns out a good tech faster than spending an afternoon proving the network is fine because no tool can say it authoritatively. Meanwhile the business sees the outcome that matters: slow MTTR, SLA misses, and the quiet conclusion that IT is the problem.
How AlertMonitor Closes the Gap
AlertMonitor was built on the opposite trade: continuous, complete visibility as the default, with everything else layered on top.
Continuous discovery, not quarterly scans. AlertMonitor discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints — using SNMP, ARP, and active scanning. Discovery runs continuously, so the device installed yesterday afternoon appears on the map before the first ticket about it arrives.
A topology map that reflects reality right now. The live map updates the moment the network changes. When a switch goes offline, a link drops, or a new device appears, an alert fires with full network context: what the device is, where it sits in the topology, what connects through it, and what changed. New hires stop being told "the diagram is mostly right, except the second floor."
Alerts that answer the first question instead of creating five more. "Device Down: SW-BRANCH-02" becomes "SW-BRANCH-02 unreachable — uplink on CORE-01 port Te1/0/2 down, 14 downstream devices affected." That is the difference between a 45-minute 2 a.m. investigation and a five-minute one — and between waking the networking contractor or not.
One workflow instead of five tabs. Because monitoring, RMM, helpdesk, and patch management share one platform, the flapping-uplink scenario plays out differently: the link errors trip an alert, the alert carries the affected-device list, a ticket is created or attached automatically with that context, and the tech fixes it remotely from the same console. MSPs get the same model for every client from one NOC dashboard — per-client topology and alerting, not twelve browser tabs across five tools.
The before-and-after is not subtle. A scenario that used to consume 60–90 minutes across four tools and two technicians resolves in 5–10 minutes in one, because nobody spends the first half hour reconstructing context the platform already had.
What You Can Do Today
You do not have to accept blind spots while you evaluate platforms. Run this audit this week.
1. Verify you can actually poll your network devices. If SNMP is not enabled on your switches, firewalls, and APs, no monitoring product can see them properly. From any Linux box:
# Replace community and IP with your own — expect a list of interface states
snmpwalk -v2c -c YourCommunity 192.168.1.2 IF-MIB::ifOperStatus
If that times out, SNMP is off or filtered, and your network is darker than you think.
2. Find the devices your inventory does not know about. Pull live ARP entries from a domain-joined workstation and compare them against your known-device list:
# Flag live neighbors that are not in your inventory export
$inventory = Import-Csv C:\IT\known-devices.csv
$live = Get-NetNeighbor -AddressFamily IPv4 |
Where-Object { $_.State -in 'Reachable','Stale' -and $_.IPAddress -notlike '169.254.*' -and $_.IPAddress -notlike '224.*' }
$unknown = $live | Where-Object { $_.LinkLayerAddress -notin $inventory.MAC }
$unknown | Select-Object IPAddress, LinkLayerAddress | Format-Table -AutoSize
Every MAC in that output is a device your RMM has never seen: a camera, a switch under a desk, a contractor laptop. On most mid-size networks the first run surfaces 5–15 percent more devices than the inventory.
3. Baseline latency to critical infrastructure, so that when a user says "the database is slow" you can separate an application problem from a network path problem in seconds:
# A large gap between average and maximum latency means loss or jitter on the path
Test-Connection -ComputerName sql-prod-01 -Count 20 |
Measure-Object -Property ResponseTime -Average -Maximum
Run it against your default gateway and one remote site too, and write the numbers down. "Normal" is only useful if you know what it is. (On PowerShell 7, the property is Latency instead of ResponseTime.)
4. Turn the audit into a standing process in AlertMonitor. Enable continuous discovery per site, then set alert policies for the three events that catch nearly every silent failure: device offline, link state change, and new device detected. Route those alerts into the integrated helpdesk so network events and their user-facing tickets land in one place, already correlated. Then retire the quarterly scan and the Visio file — the live map replaces both.
The Tail Latency of IT Operations
The P99 CONF speakers are right: the worst one percent defines the user experience. The same is true of IT operations. The well-monitored 99 percent of your infrastructure almost never pages you. Your reputation — and your on-call sleep — is decided by the one percent you cannot currently see: the flapping link, the unknown device, the half-dead switch in a closet nobody has visited since the office moved.
Database engineers refuse to guess at latency. Stop guessing at your network topology. Continuous discovery and a live map are how you buy back the hours your team currently spends reconstructing context that should have been in the alert.
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.