'Everything Is Up' While Users Suffer: Closing the Network Visibility Gap That Leaves IT Teams Blind

The Register reported this week that London's mobile networks have fallen to the bottom of Ookla's league table for European capitals — last place for speed, last place for latency. There was no outage. No fire, no flood, no routing meltdown. Rooftop rent disputes saw capacity quietly removed, planning refusals blocked replacement sites, and congestion quietly finished the job. Every operator will tell you their network is operational. Every frustrated user in London will tell you that's not the point — what people experience is the latency, not the status page.

Swap 'London' for your office and the story lands uncomfortably close to home. Most IT teams are running internal networks in exactly this state: everything technically up, users quietly suffering, and a monitoring stack that stays green from Monday morning to Friday evening.

Why 'Up' Is the Wrong Question

Here's the scenario every sysadmin recognizes. Monday, 8:40 AM. The helpdesk queue fills with 'the Wi-Fi is terrible on the third floor' tickets. You open the monitoring dashboard: every device green. The switch answers ping. The AP is up. The internet circuit shows 12 percent utilization. By every metric your tooling collects, nothing is wrong — and forty people still can't run a Teams call.

What actually happened: a power blip over the weekend, and when the distribution switch port feeding that floor's AP came back, it renegotiated at 100 Mbps instead of 1 Gbps. Or error counters started climbing on an uplink with a marginal fiber patch lead. Or the IP camera cluster someone installed on Friday is saturating an access switch uplink every afternoon. None of these conditions are 'down.' And up/down checks — which is what most RMM agents and standalone pollers actually do on the network side — will never see them.

This is the London problem in miniature: capacity and quality degraded while the status stayed green, and the people who felt it first — and reported it first — were the users. If your monitoring only learns about network problems when a human files a ticket, your monitoring is a suggestion box.

Where Existing Tooling Falls Apart

Walk through how this plays out with the typical fragmented stack — an RMM for servers and endpoints, a standalone network monitor that pings devices, a separate helpdesk, and a Visio diagram last touched in 2019:

• The monitor polls boxes, not paths. It knows core-sw01 is reachable. It has no idea that the third-floor AP uplinks through it, at what speed, or with what error rate. Latency and packet loss — the two metrics users actually experience — either aren't collected or aren't tied to anything actionable.
• Discovery is a scheduled event, not a live state. Quarterly scans, spreadsheets, CMDB exports from last year. Between scans, the map is fiction. The camera mounted in the warehouse in March, the unmanaged switch daisy-chained off a desk port — invisible until they cause an incident.
• The tools don't share context. The helpdesk ticket says 'slow Wi-Fi, floor 3.' The network monitor says green. Connecting them requires a human: which AP serves floor 3? Which switch port is it patched into? What else shares that uplink? That's 30–45 minutes of triage per ticket, done from memory and stale diagrams, by whichever technician happens to know the building.
• SLA reporting is a reconciliation project. The helpdesk reports 14 network tickets at an average of 6 hours to resolve. The monitoring tool reports 99.98% uptime. Neither number describes the three days forty users spent on a duplex mismatch. When the IT manager needs a real network health report, it's an afternoon of spreadsheet archaeology — and the answer still isn't trustworthy.

The business impact is concrete. A 500-user organization easily generates 15–25 'network is slow' tickets a week; at 30+ minutes of blind triage each, that's most of a technician's week spent confirming that monitoring missed something. MTTR on genuine network incidents doubles or triples when nobody has topology context. Branch offices with latent ISP congestion go unchallenged for months because no one can prove where the loss starts. And burnout compounds, because fighting degradation blind is the most demoralizing work in IT.

How AlertMonitor Closes the Gap

AlertMonitor was built around a simple premise: the monitoring system should know what the network actually looks like right now — not what it looked like at the last scheduled scan.

• Continuous discovery, not quarterly sweeps. Using SNMP, ARP, and active scanning, AlertMonitor continuously discovers and maps every device on the network — switches, firewalls, access points, printers, IP cameras, and unmanaged endpoints. A new device appearing on a VLAN is an event with an alert, not a surprise discovered in next quarter's scan.
• A topology map that reflects reality. The live map updates as the network changes. When a switch goes offline, a link drops, or a port renegotiates, an alert fires instantly with full context: which device, where it sits in the topology, what's connected behind it, and which users or sites are affected.
• Alerts with network context, not just device context. 'Gi1/0/24 on floor3-sw01 renegotiated from 1 Gbps to 100 Mbps — uplink for AP-3F-02 serving 38 clients' is an actionable alert. 'Device is up' is not.
• One platform instead of four. Because monitoring, helpdesk, RMM, and patch management live in the same product, the alert and the ticket are the same object. Monday's 'slow Wi-Fi' ticket arrives pre-linked to the AP, the switch, the path — and to the alert that fired at 8:02 AM, before the first user called.

The workflow difference, concretely: old way — ticket arrives, tech checks the RMM (nothing), checks the network monitor (all green), walks the floor, traces patch cables, consoles into the switch, finds the duplex mismatch on Wednesday. AlertMonitor way — the renegotiation alert fires the moment it happens, the ticket auto-attaches the topology path, and the tech fixes negotiation in under two minutes. A three-day, forty-user degradation becomes a non-event. That's the difference between a multi-day MTTR and a 90-second one — multiplied across every incident, every client, every site.

What You Can Do Today

Whether or not your tooling is ready, run these four checks this week. They measure exactly what up/down monitoring can't see.

1. Baseline latency and loss across critical infrastructure — from a server or monitoring vantage point, not your desk:

# Latency baseline for critical infrastructure
$targets = @(
    "dc01.corp.local",
    "core-sw01.corp.local",
    "fileserver01.corp.local",
    "10.20.0.1"   # branch office router
)

foreach ($t in $targets) {
    $samples = 1..20 | ForEach-Object {
        $r = Test-Connection -ComputerName $t -Count 1 -ErrorAction SilentlyContinue
        if     ($null -ne $r.Latency)      { $r.Latency }       # PowerShell 7+
        elseif ($null -ne $r.ResponseTime) { $r.ResponseTime }  # Windows PowerShell 5.1
    }

    if ($samples.Count -eq 0) {
        [PSCustomObject]@{ Target = $t; Received = "0/20"; AvgMs = "unreachable"; MaxMs = "-" }
        continue
    }

    $stats = $samples | Measure-Object -Average -Maximum
    [PSCustomObject]@{
        Target   = $t
        Received = "$($samples.Count)/20"
        AvgMs    = [math]::Round($stats.Average, 1)
        MaxMs    = $stats.Maximum
    }
}

Anything more than a couple of milliseconds average on a LAN path, or a received count below 20/20, is congestion or a physical-layer problem that no up/down check will ever flag.

2. Hunt duplex mismatches and dying ports via interface error counters. Climbing errors on an 'up' port is the classic signature:

#!/usr/bin/env bash
# Interface error counters from a switch - rising errors on an "up" port
# usually means duplex mismatch, bad cable, or a failing transceiver
SWITCH="10.0.0.2"
COMM="your-readonly-community"

echo "--- ifDescr ---"
snmpwalk -v2c -c "$COMM" "$SWITCH" 1.3.6.1.2.1.2.2.1.2
echo "--- ifOperStatus (1 = up) ---"
snmpwalk -v2c -c "$COMM" "$SWITCH" 1.3.6.1.2.1.2.2.1.8
echo "--- ifInErrors ---"
snmpwalk -v2c -c "$COMM" "$SWITCH" 1.3.6.1.2.1.2.2.1.14
echo "--- ifOutErrors ---"
snmpwalk -v2c -c "$COMM" "$SWITCH" 1.3.6.1.2.1.2.2.1.20

3. When a site is 'slow,' trace the path, not just the endpoint:

# 100 packets, report mode - shows WHERE latency and loss begin on the path
mtr -rwbzc 100 --no-dns 10.20.0.1

Read the Loss% column hop by hop. Loss appearing at an internal hop and persisting to the end means the problem is inside your network; loss only at the final hop points to the remote end or the ISP. This one command usually settles the branch-office finger-pointing debate that otherwise drags on for weeks.

4. Find out what is actually on your network right now:

# Devices responding on 10.0.4.0/24 that are NOT in your known inventory
# (requires PowerShell 7 for ForEach-Object -Parallel)
$subnet = "10.0.4"
$known  = @("10.0.4.5","10.0.4.10","10.0.4.22","10.0.4.31")

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

On Linux, arp-scan does the same job and includes the MAC vendor, which usually identifies the device type:

sudo arp-scan --interface=eth0 --localnet

Every unknown device is either an inventory gap or tomorrow's incident. It's also a reminder of what discovery should be: continuous, automatic, and alerting. With AlertMonitor, the ARP sweep, the comparison against live inventory, and the alert on anything new run all the time — not when someone remembers to run a script.

Run these checks once and you will almost certainly find at least one 'green but wrong' condition in your environment this week. Then ask the harder question: why did it take a human with a script to find it?

The Bottom Line

London's operators are learning what IT teams learn the hard way: infrastructure that is 'up' can still be failing everyone who depends on it. Speed, latency, and capacity are what users actually experience, and they degrade long before anything turns red. Real visibility means knowing the state of every device, every link, and every path — right now — and being told the moment any of it changes. That's what turns a helpdesk that reacts to complaints into an IT team that beats the first call to the punch.

Related Resources

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