This week, The Register reported that Docmail — the UK's cloud print-and-post service — had been stuck for a third straight day, with tens of thousands of letters sitting in a digital outbox and no restoration ETA in sight. More than 30,000 UK organizations depend on the platform, including NHS trusts and GP practices that rely on it for appointment reminders and patient correspondence.
Here's the part that should make every sysadmin, IT manager, and MSP tech squirm: of those 30,000 organizations, very few learned about the failure from their monitoring stack. They learned it from a receptionist. A phone call. A ticket that read, in its entirety, "letters aren't going out."
That pattern — end users as your detection layer — isn't unique to a SaaS mail outage. It's happening in your environment right now, at smaller scale, every week. The question this article answers is simple: when something breaks, does your network tell you, or does a human tell you?
The Story Isn't the Outage. It's How Everyone Found Out.
Services fail. Vendors have bad weeks. Nobody reasonably expects any platform to run a decade without a major incident. What's inexcusable in 2026 is the detection model most IT teams still run:
- A print server's spooler hangs at 08:40. The monitoring tool polls the box every five minutes and reports it UP — because the OS answers ping. The first user ticket lands at 09:25. The outage clock started 45 minutes before anyone in IT knew.
- An MSP's branch office switch starts flapping the uplink that feeds the print VLAN. Three clients call in before anyone in the NOC notices the interface errors — buried in a network monitor that nobody correlates with the helpdesk queue.
- Practice managers, staring at a vendor status page they didn't know existed, burn staff hours manually calling patients whose appointment letters never arrived.
Detection lag is the tax you pay for bad visibility, and it compounds: the later you detect, the longer the fix, the bigger the ticket queue, the worse the SLA report, the angrier the users, the faster the techs burn out.
The Problem in Depth: Why Modern IT Teams Are Still Blind
1. Device monitoring is not service monitoring
Most RMM and monitoring platforms — older N-central and Automate setups, vanilla Nagios installs, basic ping checks in PRTG or Zabbix — answer one question: "Is the device up?" A server can be up, the switch port up, the firewall green, and the actual business function — print, mail relay, the API call to a service like Docmail — completely dead. Monitoring the node instead of the path is why outages get discovered by receptionists.
2. Discovery that runs quarterly is documentation, not visibility
Plenty of shops still run network discovery as a nightly or weekly job and treat the output as inventory. In the 23 hours between scans, a new device can join the network, a link can drop, a switch can silently die. Then someone opens the Visio diagram from 2023 to troubleshoot and finds it documents a core switch that was decommissioned eight months ago. You cannot resolve an incident against a map of a network that no longer exists.
3. Siloed tools mean every alert is a guessing game
The typical mid-size IT stack: an RMM for endpoints, a standalone network monitor, a helpdesk for tickets, Visio or Excel for topology, and the vendor's status page for SaaS. None of it talks. So when "the letters aren't going out" arrives as a ticket, the tech's triage looks like this:
- Check the print server in the RMM (tab 1)
- Check the switch interface in the network monitor (tab 2)
- Check the firewall rules (tab 3, console access)
- Check the vendor status page (tab 4)
- Ping the one colleague who "knows the network" (Slack)
Twelve tabs, five tools, twenty minutes — before a single remediation step. And because the helpdesk and the monitor don't share data, nobody can answer the manager's question — "how long were we actually down, and how many users were affected?" — without exporting CSVs and doing archaeology in Excel.
4. What this costs, in numbers a practitioner recognizes
- Detection lag: user-reported outages routinely carry 30–60 minutes of undetected downtime. At five to ten such incidents a week, that's a full working day of invisible breakage every month.
- Ticket volume: for an MSP, one shared dependency failing across 12 clients can generate 40+ tickets in an hour, each phrased differently, none with context. Triage becomes guesswork.
- SLA misses: if the SLA clock starts at first contact instead of first failure, a one-hour response SLA is already blown before the tech opens a console.
- Morale: nothing burns out a good tech faster than firefighting blind — being paged at 2 a.m. because a disk filled up and the monitor didn't say so, or spending a morning proving an outage "wasn't us" when the evidence lives in a tool nobody can export from.
How AlertMonitor Solves This
Continuous discovery: the map that never goes stale
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. Not quarterly. Not nightly. Continuously. When a switch goes offline, a link drops, or a new device appears, an alert fires instantly with full network context. There is no 23-hour blind window and no Visio diagram to distrust.
Alerts with context, not just state
Instead of "Host 192.168.14.2 unreachable," the AlertMonitor alert reads: "SW-BR01 offline; uplink Gi0/24 down; 3 downstream devices affected including PRN-BRANCH01 on the print VLAN; 12 users impacted." The tech opens one screen and knows the blast radius before touching a keyboard. That's the difference between a 20-minute triage and a 90-second response.
Dependency-aware monitoring for internal and external services
AlertMonitor lets you watch the path, not just the node: DNS resolution, TCP reachability, SNMP interface states on the switch ports feeding critical VLANs, and connectivity to the external endpoints your business runs on. When a Docmail-style third-party service stops answering — or the route to it breaks inside your own firewall — you know in seconds, from one dashboard, before reception picks up the phone.
One platform: monitoring, helpdesk, RMM, and patching together
This is where unified beats assembled. In AlertMonitor, the network alert automatically creates and links a helpdesk ticket with the affected devices attached; the tech jumps into remote management from the same screen; patch state and service status are visible without switching tools. For the MSP, that's one NOC dashboard for every client instead of five tabs per client.
Old way: user ticket → five tools → 20 minutes of triage → fix → CSV export to answer "how bad was it?"
AlertMonitor way: instant correlated alert with topology context → linked ticket with device context → one-click remote remediation → MTTR cut from an hour to minutes, with the SLA report generated from the same data.
Practical Steps You Can Take Today
1. Measure how outages actually get detected. Pull last quarter's tickets and count how many P1/P2 incidents were user-reported first. If it's more than a handful, your monitoring has a visibility gap — whatever the dashboards claim.
2. Monitor your external dependency paths actively. For every SaaS your organization runs on, script a DNS + TCP reachability check and feed it into your monitoring:
# Verify DNS + TCP reachability for critical third-party dependencies
# Schedule every 5 minutes and alert on failures
$targets = @(
@{ Name = "Docmail API"; Hostname = "api.docmail.co.uk"; Port = 443 },
@{ Name = "Print relay"; Hostname = "prnrelay.corp.local"; Port = 9100 }
)
foreach ($t in $targets) {
try {
$dns = (Resolve-DnsName $t.Hostname -ErrorAction Stop |
Where-Object Type -eq 'A' | Select-Object -First 1).IPAddress
$tcp = Test-NetConnection -ComputerName $t.Hostname -Port $t.Port -WarningAction SilentlyContinue
"{0,-12} DNS: {1,-16} TCP {2}: {3}" -f $t.Name, $dns, $t.Port, $tcp.TcpTestSucceeded
}
catch {
"{0,-12} DNS RESOLUTION FAILED" -f $t.Name
}
}
3. Rule out your own stack before blaming upstream. When a third-party service breaks, half your users will assume IT broke. Prove in 30 seconds that your print path is healthy:
# Confirm the Print Spooler is running on every print server
# before escalating to the third-party vendor
$printServers = @("PRN01", "PRN02", "PRN-BRANCH01")
Invoke-Command -ComputerName $printServers -ScriptBlock {
Get-Service -Name Spooler | Select-Object Name, Status, StartType
} | Select-Object PSComputerName, Name, Status, StartType | Format-Table -AutoSize
4. Baseline your network and diff it for changes. New or unexpected devices are how outages and misconfigurations start. Even before a platform, start with a repeatable baseline:
# Snapshot the ARP table and diff it against the last known-good state
# to surface new or unmanaged devices on the network
sudo arp-scan --localnet > /tmp/arp-now.txt
diff /opt/baseline/arp-baseline.txt /tmp/arp-now.txt | grep '^>'
# After reviewing, refresh the baseline:
cp /tmp/arp-now.txt /opt/baseline/arp-baseline.txt
5. Replace periodic scans with continuous discovery. If your current answer to "what's on the network right now?" involves the word "Visio," it's time to see what a live topology map does to your MTTR. AlertMonitor's network visibility module discovers switches, firewalls, APs, printers, and unmanaged endpoints continuously, and fires contextual alerts the moment the map changes.
The Takeaway
Docmail will come back. The 30,000 affected organizations will rebuild their mail queues and mostly move on. But the detection model that let a three-day outage blindside them — and that lets smaller outages blindside your team every week — won't fix itself. Stop paying the user-reported-detection tax. Know the state of your network right now, not at last scan, not last quarter.
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.