OpenAI Cut Read Latency 12x. Your Team Still Learns About Slowness From Angry Users.

OpenAI recently detailed how Habitat — its globally distributed storage platform built on Azure Cosmos DB — went from a median global read latency of about 120 ms down to 10 ms while scaling past 500 petabytes across 40 regions. Buried in that story is a lesson every IT team should steal: for a long time, OpenAI dealt with unpredictable latency from shared database containers by throwing money at the problem — dedicated containers, dedicated capacity. Only once they could actually see and fix the contention did they return to shared infrastructure.

Translate that down to your environment. A user in the branch office waiting four seconds for a folder to open doesn't file a latency report — they post "the network is slow again" in the team channel. And now you're diagnosing a problem that has been degrading for weeks, with zero data about when it started.

That's the uncomfortable truth about network performance: you don't get alerted when slowness begins. You get alerted when users give up.

The Problem: Your Monitoring Knows Devices Are Up. It Has No Idea Anything Is Slow.

Most monitoring stacks answer exactly one question well: "Is the host reachable?" Ping succeeds, box is green. Ping fails, box turns red, someone gets paged. The enormous gray zone in between — where most real user pain lives — is invisible:

• A core switch uplink throwing CRC errors and silently dropping 2% of packets. Every connection through it feels broken, but the switch answers pings, so the dashboard stays green.
• A branch office saturating its 200 Mbps circuit every morning. The firewall is up, the link is up, and Teams calls are garbage from 9:00 to 11:30 — for the fifth week running.
• A failing SFP module or a duplex mismatch on an access port making one department's machines crawl, while every uptime check passes.

The OpenAI noisy-neighbor story is the same disease at hyperscale. When shared Cosmos DB containers suffered contention, latency spiked unpredictably — so they paid for dedicated containers to escape a problem they couldn't precisely diagnose. IT teams without visibility do this constantly: "the WAN feels slow, buy more bandwidth," "the app is slow, give it a bigger VM." Without visibility, you buy your way out of mystery. With visibility, you fix the actual cause.

Why the Gaps Exist

• Tooling silos. The RMM agent checks disk, CPU, and services on endpoints. A standalone ping monitor checks reachability. Switch and firewall health lives in vendor GUIs nobody opens until something breaks. None of these systems talk, so nobody correlates "users on floor 3 report slowness" with "the uplink on that floor's switch started discarding packets Tuesday."
• Static documentation. The network map is a Visio diagram from 2021, or the onboarding spreadsheet from when the client was signed. When a ticket says "the whole third floor is slow," a tech first has to figure out which switch even serves floor 3 — by tracing cables or calling the office manager.
• Discovery runs when someone remembers. Quarterly scans mean the IP camera installed over the holidays, the unmanaged switch under a desk, and the second DHCP server nobody documented simply don't exist in your inventory until they cause an outage.
• Latency is a path property, but tools check points. Users experience end-to-end latency across DNS, the access layer, distribution, the WAN, and the server. Pinging individual devices can't tell you which segment degraded.

What It Actually Costs

• A "network is slow" ticket burns 30–60 minutes of tech time: remote in, run pings, check Task Manager, open three vendor consoles, close it as "cannot reproduce." Multiply by a few of those per week.
• SLA reporting is fiction. The helpdesk holds a complaint timestamp; the performance history lives in another tool with different retention. You can prove when the user complained, not when the degradation started — so every SLA miss looks like slow response.
• Repeat-offender sites generate the same slow-network tickets every month, each investigated from scratch, because nobody has trend data.
• MSPs feel this hardest: twelve clients, each with undocumented switches and stale maps, supported by four techs. Every site visit re-discovers what's actually plugged in.
• And morale: nothing burns out a good tech faster than tickets they cannot diagnose with the tools they've been given.

How AlertMonitor Ends the Guessing

AlertMonitor approaches this from the opposite direction: it assumes you don't know what's on your network, and it continuously finds out.

Continuous discovery via SNMP, ARP, and active scanning. Switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints appear in inventory and on the map within minutes of connecting — not next quarter. The mystery device from the ARP sweep below? It would have been flagged the moment it got a DHCP lease.

A live topology map, not a diagram. When access switch SW-F3-01 goes offline, it turns red on the map, downstream links gray out, and the alert carries full context: which switch, which port, which 14 endpoints and the floor-3 AP are affected. Instead of "192.168.10.5 unreachable," the on-call tech gets "access switch offline — 18 users impacted at the Riverside site." That's the difference between a page and a diagnosis.

Link-level alerting. Rising interface errors, discards, and dropped links fire alerts with network context attached — catching a degrading uplink while the dashboard is still green and users haven't noticed yet.

Alerts become tickets automatically. Because monitoring, helpdesk, RMM, and patching share one platform, an alert creates a ticket pre-populated with the device, location, topology, and affected users. The tech acknowledges, launches a remote session, resolves, closes — one timeline, no copy-pasting across five tools. SLA reports come from the same system that detected the problem, so the data finally matches reality.

For MSPs: one NOC across every client. Each client's live map, inventory, and alerting in a single console, with alerts routed per client and per SLA. A new client gets an accurate, live network map in hours — not weeks of cable tracing.

The Workflow, Before and After

Before: 10:40 — a user tickets "everything is slow." The tech remotes in, pings around, checks the ping monitor (green), calls the branch office to have someone look at switch lights. 10:55 — opens the hypervisor console. 11:20 — finally consoles into the switch and finds the error counters climbing on the uplink. Root cause found 40 minutes after the complaint; the degradation started days earlier.

After: 10:12 — interface errors on the floor-3 uplink cross the threshold. An alert fires and a ticket is auto-created with the port, the switch, and every affected endpoint mapped. 10:14 — the tech sees it, remotes in, replaces the patch cord. The first "network is slow" complaint never gets written.

What You Can Do Today

You won't rip out your stack this afternoon, but you can start collecting the evidence you're currently missing.

1. Baseline latency to your critical servers.

$servers = "dc01.corp.local", "file01.corp.local", "app01.corp.local"

foreach ($server in $servers) {
    $pings = Test-Connection -ComputerName $server -Count 10 -ErrorAction SilentlyContinue
    if ($pings) {
        $avg = ($pings | Measure-Object -Property ResponseTime -Average).Average
        "{0,-25} avg {1:N1} ms" -f $server, $avg
    }
    else {
        "{0,-25} UNREACHABLE" -f $server
    }
}

If a domain controller on the same subnet answers in 1 ms and the file server averages 40 ms, you have a path problem, not an application problem — and now you have evidence instead of a hunch.

2. Log latency over a day to catch time-of-day patterns.

# Run on an always-on machine; logs WAN latency every 5 minutes
$target = "8.8.8.8"
$log = "C:\logs\wan-latency.log"

while ($true) {
    $r = Test-Connection -ComputerName $target -Count 4 -ErrorAction SilentlyContinue |
         Measure-Object -Property ResponseTime -Average
    "{0}  avg {1:N1} ms" -f (Get-Date -Format "yyyy-MM-dd HH:mm"), $r.Average |
        Add-Content -Path $log
    Start-Sleep -Seconds 300
}

After a week you'll know whether your "slow mornings" are a saturated site-to-site VPN at 9:00 or somebody's cloud backup job. That's noisy-neighbor diagnosis on your own WAN.

3. Check switches for interface errors and discards via SNMP.

COMMUNITY="your-read-only-community"
SWITCH="core-sw01.corp.local"

snmpwalk -v2c -c "$COMMUNITY" "$SWITCH" IF-MIB::ifInErrors
snmpwalk -v2c -c "$COMMUNITY" "$SWITCH" IF-MIB::ifOutErrors
snmpwalk -v2c -c "$COMMUNITY" "$SWITCH" IF-MIB::ifInDiscards
snmpwalk -v2c -c "$COMMUNITY" "$SWITCH" IF-MIB::ifOutDiscards

Non-zero error or discard counters on an uplink are the classic signature of a degrading cable, a dying transceiver, or congestion — visible long before anything shows "down."

4. Find out what's actually on a subnet.

# Ping sweep a /24 to populate ARP, then list live devices
$subnet = "192.168.10"
1..254 | ForEach-Object {
    Test-Connection -ComputerName "$subnet.$_" -Count 1 -ErrorAction SilentlyContinue | Out-Null
}
arp -a | Select-String $subnet

# Same idea from a Linux box
for i in $(seq 1 254); do
  ping -c1 -W1 192.168.10.$i >/dev/null 2>&1 && echo "192.168.10.$i alive"
done
arp -a

Compare the output to your inventory. Every address you can't name is either a documentation failure or a problem — on most networks, it's both.

5. Stop doing this by hand. A manual sweep tells you about one subnet at one moment in time. AlertMonitor runs discovery continuously across every subnet, keeps the topology map live, and turns new devices, dropped links, and degrading interfaces into alerts with full context — which is the actual job. OpenAI didn't fix Habitat by pinging harder; they fixed it by seeing the contention. Your network deserves the same treatment at your scale.

Related Resources

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