387 Outages in One Week: Know in 90 Seconds Whether It's Your Network, Your ISP, or Your Cloud Provider

ThousandEyes, Cisco's internet intelligence arm, just published its weekly health check for October 12–18: 387 network outage events across ISP backbones, cloud provider networks, collaboration app networks, and edge infrastructure — DNS, content delivery networks, and security-as-a-service. That's 387 failures in seven days, somewhere in the stack your users depend on to do their jobs. Roughly 55 a day, globally, on somebody's critical path.

Here's what that number means in practice. Every one of those outages landed on somebody's helpdesk as "the internet is down" or "Teams isn't working." And in most IT shops, the response looked the same: a senior tech opens four tools, pings five things, and burns 45 minutes figuring out whether the problem lives in the server room, the ISP's backbone, or a CDN edge node two time zones away.

The internet breaking is not your fault. Taking an hour to figure out whose fault it is — that's a tooling problem, and it's fixable.

The Tuesday Morning Scenario Every IT Team Knows

9:40 a.m. Teams calls start dropping mid-sentence. By 9:55 there are 22 tickets in the queue, all variations of "is it down for you too?"

Now the triage dance:

1. RMM console (NinjaOne, ConnectWise, Datto — pick yours): agents online, CPU idle, disks fine. Endpoints are healthy.
2. Standalone network monitor (PRTG, LibreNMS, the aging SolarWinds box): firewall green, core switch green, internet feed green. Ping says everything's fine.
3. ISP and Microsoft status pages: all green — because status pages are written by communications teams, not by packet capture.
4. RDP into a workstation, run tracert to teams.microsoft.com, squint at hop 7, and argue about whether 40 ms is normal.
5. 40–60 minutes later, someone spots a post in a peer community: a major edge provider is having a bad day. It wasn't you. It was never you.

You just burned an hour of your most expensive technician on an outage you couldn't prevent, produced zero documentation for 22 tickets, and now you get to explain the response time to the IT manager. Multiply that by 55 outages a day happening somewhere in the world, and a meaningful slice of your week is spent triaging failures that were never yours to fix.

Why Your Current Stack Can't Answer "Whose Problem Is This?"

RMM agents watch the endpoint, not the path. They'll happily tell you the laptop is fine while the WAN link is flapping. Useful, but blind to the question users are actually asking.

Standalone monitors watch device up/down, not topology or dependencies. Ping-green is not service-working. A monitor that pings the firewall cannot tell you that DNS resolution is failing upstream, that a CDN edge is returning errors, or that an unmanaged switch in the second-floor closet just dropped 14 people off the network — because it doesn't know that switch exists.

Discovery data is stale. Most teams are triaging against a Visio diagram from 2021 or the last quarterly scan. The contractor switch added in March, the rogue access point someone plugged into conference room 4, the IP cameras on the warehouse VLAN — none of it is on the map. When the map is wrong, triage goes wrong.

The helpdesk and the monitoring live in different systems. So when a provider outage hits, you don't get one incident — you get 22 independent tickets, each handled by hand, none linked to the root cause. And when you want to claim SLA credits from the ISP, you discover you have no evidence trail, because your monitoring data and your ticket data cannot be joined.

Status pages are reactive PR. By the time the provider posts an update, you've already lost the hour.

The result is predictable: inflated MTTR, ticket storms from single root causes, SLA credits left on the table, and the quiet credibility erosion that happens every time users see "all systems green" on the monitoring wall while everything is on fire.

How AlertMonitor Changes the First 90 Seconds

AlertMonitor was built around a simple idea: you can't triage what you can't see, and you can't see a network you discovered last quarter.

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. The live topology map is always current. The contractor switch from March is on it. The rogue AP in conference room 4 is on it, flagged as a new device the moment it appeared.

Alerts fire with full network context. When a switch goes offline, a link drops, or a new device appears, the alert includes what it is, where it sits in the topology, and which downstream devices and users are affected. You don't get "host 192.168.10.47 unreachable" — you get "uplink port Gi1/0/24 on SW-FLOOR2 dropped; 14 endpoints in Accounting affected." That's the difference between a triage session and a fix.

Internal vs. external in one glance. Users report Teams is down. Your internal map is green — every switch, link, and gateway healthy. You already know the answer: it's upstream. Post an internal notice, link the tickets to a master incident, move on. Ninety seconds instead of an hour.

One platform instead of five tabs. The alert auto-creates a helpdesk ticket with the device context attached. From the same console, a tech can use RMM to restart a service or push a remediation script to an affected endpoint, and check patch status on the same device record. No correlation gymnastics between tools that don't talk to each other.

The before/after is not subtle:

What You Can Do Today

1. Baseline your external dependencies — while everything works. You can't recognize "abnormal" if you never recorded "normal." Run this from a workstation and from a server, and save the output:

# external-baseline.ps1 — run now, save the output as your known-good baseline
$targets = @(
    @{ Name = "Default gateway"; Addr = (Get-NetRoute -DestinationPrefix "0.0.0.0/0" | Select-Object -First 1).NextHop },
    @{ Name = "Public DNS";      Addr = "8.8.8.8" },
    @{ Name = "M365 auth";       Addr = "login.microsoftonline.com" },
    @{ Name = "Exchange Online"; Addr = "outlook.office365.com" },
    @{ Name = "Teams";           Addr = "teams.microsoft.com" }
)

foreach ($t in $targets) {
    $ok = Test-Connection -ComputerName $t.Addr -Count 3 -Quiet -ErrorAction SilentlyContinue
    "{0,-18} {1}" -f $t.Name, $(if ($ok) { "OK" } else { "UNREACHABLE" })
}

Next outage, run it again. Gateway unreachable = your problem. Gateway fine but M365 unreachable = provider problem. That single distinction wins most of the triage battle.

2. Bisect the path mechanically, not emotionally. From any Linux box or WSL:

#!/usr/bin/env bash
# path-bisect.sh — gateway down = your problem; gateway fine + 1.1.1.1 down = upstream
GW=$(ip route | awk '/^default/ {print $3; exit}')

echo "=== Hop 1: local gateway (${GW}) ==="
ping -c 4 -W 2 "$GW" | tail -2

echo
echo "=== End-to-end: 1.1.1.1 ==="
ping -c 4 -W 2 1.1.1.1 | tail -2

echo
echo "=== Per-hop loss and latency ==="
mtr --report --report-cycles 10 1.1.1.1

If hop 1 is clean and loss starts at hop 3, you have evidence in hand before the ISP's status page even knows it has a problem. That's what you attach to the ticket when you claim the SLA credit.

3. Find your blind spots tonight. Every MAC address that comes back and isn't in your inventory is a device your map doesn't know about:

# blind-spot-sweep.ps1 — requires PowerShell 7+ for -Parallel
$subnet = "192.168.10"   # change to your VLAN

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

$live | ForEach-Object {
    [pscustomobject]@{
        IP  = $_
        MAC = (arp -a $_ | Select-String "([0-9a-f]{2}-){5}[0-9a-f]{2}").Matches.Value
    }
} | Sort-Object { [version]$_ } | Format-Table -AutoSize

Run it once manually and you will find things. Then stop running it manually: this is exactly the sweep AlertMonitor performs continuously via SNMP and ARP, with a "new device detected" alert wired straight to your ticket queue.

4. Retire the stale map. In AlertMonitor, enable SNMP polling on every managed switch and firewall, turn on scheduled discovery for every VLAN, and set escalation so a WAN link down for more than 60 seconds opens a P1 ticket automatically. The Visio diagram goes in the recycle bin, where it belongs.

5. Wire alerts to the helpdesk — with context. Every network alert should arrive as a ticket that already says what broke, where it sits in the topology, and who is affected. If your current stack can't do that natively, that's not a feature gap. That's the product problem.

The Internet Will Break 387 Times Next Week, Too

ThousandEyes will publish the count again next Friday, and it will not be zero. You can't prevent a single one of those outages. What you can control is whether your team spends the next one performing five-tool triage theater — or knows in 90 seconds, with evidence attached, exactly whose problem it is.

Live topology, continuous discovery, and alerts that carry context don't just make the dashboard prettier. They cut the hour between "users are screaming" and "we know what's broken" down to seconds — and that hour is where your real downtime, your real ticket volume, and your real burnout live.

Related Resources

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