Last week, The Register reported that a UK school admitted a data protection bungle after a thief snatched a school photographer's SD cards in a smash-and-grab, putting children's data at risk. Set the particulars aside for a second — this wasn't a phishing campaign, a zero-day, or a ransomware crew. It was a person, a broken window, and a bag of memory cards.
That is exactly why it deserves an IT manager's attention. Strip away the details and you're left with the pattern behind most operational disasters: the organization didn't detect the incident. Nothing in its own systems raised a hand. The first meaningful alert arrived from the outside world — in this case, a break-in. By the time anyone internally knew anything, the response had already become damage control.
If you run infrastructure for a living, you know this moment intimately. Every sysadmin has a version of the smash-and-grab story:
- The Exchange queue backing up that you learned about from a receptionist who "couldn't send emails since lunch"
- The branch office offline since Saturday that surfaced Monday at 09:15 when the office manager finally called
- The backup job that had been silently failing for three weeks, discovered the day you actually needed the restore
- The expired certificate that took down MFA, reported first by the CEO's very public angry message
The trigger doesn't matter. The discovery lag does. And when the incident involves personal data, discovery lag stops being an annoyance and becomes a regulatory event. UK GDPR gives you 72 hours to notify the ICO of a personal data breach. IBM's Cost of a Data Breach research has consistently placed the average time to identify a breach near 200 days. That gap — between a 72-hour obligation and a multi-month detection reality — is where careers and companies get hurt.
The Problem: Detection That Exists on Paper Only
You can't alert on what you never inventoried
The stolen SD cards were, functionally, unmonitored assets carrying production data. No check-in, no owner watching, no signal when something went wrong. Your environment is full of equivalents:
- Laptops that left the office months ago and never check in anymore
- A NAS under a desk at a branch that "someone" set up in 2021
- Vendor-managed devices — cameras, door controllers, HVAC gateways — that no RMM agent will ever touch
- Local exports and folders that replicate to nothing
Most RMM platforms only see what has a healthy agent. If a device doesn't check in, no alert fires — and worse, the silence isn't treated as a signal at all. It's treated as nothing. That is the root cause of every "we had no idea" moment, including the school's.
Alerts that fire into dead channels
Plenty of organizations technically have monitoring. The alert goes to monitoring@company.com — an inbox checked when someone is bored — or to a console staffed nine to five. An alert nobody acknowledges is functionally identical to no alert. Arguably it's worse, because it creates the paperwork of coverage without the substance, so leadership believes you're protected while you aren't.
Noise trains your team to ignore pages
A monitoring tool that pages on every heartbeat blip, warns at disk thresholds nothing ever meets, and fires 400 alerts when one switch reboots is actively training your on-call techs to swipe notifications away half-asleep. After the fiftieth pointless 2am page, the fifty-first — the one that matters — gets dismissed too. Alert fatigue is not a discipline problem on your team's side. It's a signal quality problem on the tooling side.
No context makes triage expensive — so triage gets deferred
"ALERT: Disk usage high on SRV-03" at 2am tells the on-call tech nothing. Which client? Which volume? Filling because of logs, or is the disk actually dying? What did healthy look like? To answer, the tech opens an RMM, a separate monitoring console, and a file browser. When triage is that expensive, humans defer it until morning — and deferred triage is how a fifteen-minute fix becomes a six-hour, user-visible outage.
When something does happen, nobody can size the blast radius
The school couldn't immediately say what data those cards held. The IT equivalent: a client calls to say a contractor walked off with a laptop, and within the hour nobody can answer what that device had access to, what was stored locally, or when it last checked in. Fragmented tooling turns that question into archaeology across an RMM, a separate monitor, a separate helpdesk, and someone's spreadsheet — while the 72-hour clock runs.
Why these gaps exist
Nobody chose this. Tools were bought department by department over a decade: monitoring from one vendor, RMM from another, helpdesk from a third, patching from a fourth. Each stores alerts its own way, has its own severity scale, and none of them talk to each other. Escalation logic lives in one senior technician's head. Legacy monitoring platforms were designed to ping devices and light up a wallboard — not to guarantee that a specific human acknowledges a specific signal within a specific timeframe.
What it costs, concretely
- Downtime. Industry surveys have long put the cost of a single hour of unplanned downtime into five figures for mid-sized organizations — and that's before reputational damage.
- Duplicate ticket load. Every undetected incident becomes five to fifteen helpdesk tickets as users notice one by one, each burning technician minutes re-diagnosing the same problem from zero.
- Restore-day discoveries. Backup failures that never alerted get discovered the moment you need the restore — the single most expensive time to learn your coverage was fiction.
- Burnout. Techs who can't trust their tools stop sleeping properly. They wake at 2am to check the console "just in case." That's not vigilance; it's the first draft of a resignation letter.
Here's a scenario every MSP tech has lived: a client's document server starts failing its nightly backup silently. The RMM shows the backup agent "installed and running" — the service is running; it just can't reach the repository. Nobody monitors the job outcome, only the service state. Three weeks later the RAID controller dies. Nobody gets fired because a RAID controller failed — hardware fails. What ends careers is the detection that never covered the outcome and the escalation path that never existed. That is the school's SD-card story with different props: a data-bearing asset, no signal, external discovery, public apology.
How AlertMonitor Closes the Gap
AlertMonitor was built around a specific insight: alert fatigue isn't a volume problem — it's a signal quality problem. Everything in the platform follows from that.
1. One inventory, so silence is a signal. Monitoring, RMM, helpdesk, and patch management run on a single platform with one asset list per client. A device that stops checking in raises an alert. A laptop that hasn't phoned home in fourteen days becomes a decision in your queue — not a blind spot you discover during a breach call.
2. Every alert carries full context. Device, client, what changed, and what healthy looks like. Not "disk high on SRV-03," but "FS01 (Client: Northgate Primary) — D: at 8% free, baseline is 41%, growing ~4 GB/day, projected full in 2 days." The on-call tech makes a routing decision in ten seconds, from their phone, without opening anything else.
3. Escalation policies that assume humans are human. Multi-level on-call routing sends alerts to the right person by client, schedule, and severity. If an alert isn't acknowledged within the defined window, it escalates — automatically, predictably, visibly. There is no dead channel, because the platform doesn't rely on anyone remembering to check an inbox.
4. Deduplication and maintenance windows keep signal at signal strength. One switch reboot produces one correlated event with linked children, not 400 pages. Planned maintenance? Define the window and the noise is suppressed — so nothing ever teaches your team that alerts can be safely ignored.
5. Alert → ticket → fix, in one pane. The alert attaches to a helpdesk ticket with device context already populated, and the tech remediates from the same console — restart the service, run a script, push the patch. No swivel-chairing across five browser tabs to answer one client's question.
6. The audit trail writes itself. When the incident is over, the full timeline is a filtered view: when the alert fired, who acknowledged it, what actions ran, when it resolved. That's the report you hand to leadership, your insurer, or a regulator — without a week of Slack archaeology.
The same 2am, two ways
The fragmented stack: Disk starts filling at 23:47. A monitoring email sits unread in a shared inbox. The first user ticket lands at 09:12. A tech confirms the problem at 09:40 and triages from zero across four tools. Service restored at 11:30. The morning meeting is spent failing to establish when it started or what else was affected.
AlertMonitor: Disk-trend alert fires at 23:47 with client, baseline, and growth rate. Routed to on-call. Acknowledged at 23:52 — culprit identified as a runaway log directory. Cleared via script from the same pane at 00:05. Alert auto-resolves; the ticket closes with a complete timeline. Tomorrow morning, there is no tomorrow-morning meeting.
Eleven hours of user-visible outage versus a page resolved before anyone woke up is not a tooling detail. It's the entire distance between "incident handled" and "public apology."
Practical Steps You Can Take Today
1. Find the devices that aren't actually monitored
Compare what your directory says exists against what your RMM says checks in. Stale computer accounts are both hygiene debt and detection gaps:
# Computer accounts that haven't authenticated in 30+ days
Search-ADAccount -ComputersOnly -AccountInactive -TimeSpan 30.00:00:00 |
Select-Object Name, LastLogonDate |
Sort-Object LastLogonDate
Every result is one of two things: decommissioned (remove it) or unmanaged (fix it, or accept in writing that nobody will know when it has a problem).
2. Verify backups independently of your backup tool
Don't ask the agent whether it succeeded — ask the operating system:
# Last Windows Server Backup job result on a server
$last = Get-WBJob -Previous 1
$last | Select-Object StartTime, EndTime,
@{N = 'Result'; E = { if ($_.HResult -eq 0) { 'Success' } else { "FAILED ($($_.HResult))" } } }
"The service is running" and "the backup succeeded" are different statements, and only one of them protects you. Wire this check into AlertMonitor so the job outcome is monitored and escalated — not just the agent's pulse.
3. Sweep disk health across your server estate
The check you wish had fired at 2am, as a one-off sanity sweep:
# Free space on all logical disks across domain servers, flag anything under 15%
$servers = (Get-ADComputer -Filter 'OperatingSystem -like "*Server*"' -Properties OperatingSystem).Name
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter 'DriveType=3' |
Select-Object SystemName, DeviceID,
@{N = 'FreeGB'; E = { [math]::Round($_.FreeSpace / 1GB, 1) } },
@{N = 'FreePercent'; E = { [math]::Round(($_.FreeSpace / $_.Size) * 100, 1) } } |
Where-Object FreePercent -lt 15 |
Sort-Object FreePercent
Anything this script surfaces that your monitoring didn't already alert on is a coverage gap with a name on it.
4. Confirm critical services before someone else discovers they're down
# Core service liveness on a remote file server
$server = 'FS01'
Get-CimInstance -ComputerName $server -ClassName Win32_Service -Filter `
"Name='Netlogon' OR Name='Spooler' OR Name='W32Time' OR Name='LanmanServer'" |
Select-Object PSComputerName, Name, State, StartMode
5. Run a detection drill
Pick a quiet Friday evening. Stop a non-critical service or pull a lab switch. Start a timer, then answer three questions honestly:
- Did an alert fire at all?
- Did it route to a human who was actually on call?
- How long until someone acknowledged it?
If any answer is "no" or "hours," your escalation design is broken — and it is far cheaper to learn that from a drill than from the ICO. In AlertMonitor the drill is trivial to run and easier to review afterward: the alert timeline shows exactly what fired, where it routed, and when a human touched it.
6. Audit escalation quarterly
People leave. Schedules change. Distribution lists rot. Escalation policies in AlertMonitor are explicit and configurable — multi-level routing per client and severity — so the quarterly review means reading a policy, not interviewing your senior tech about what he thinks happens when the primary doesn't answer his phone.
The Takeaway
The school in this story didn't cause the theft, but it owns the aftermath — because ownership of an incident begins the moment something happens, not the moment you find out. Most IT teams are one silent failure away from the same position. Not because their tools are incapable of detecting problems, but because detection was never deliberately wired to a human being: coverage is partial, routing is informal, noise drowns signal, and there's no context to act on when the page finally arrives.
AlertMonitor exists because that wiring shouldn't be left to chance. Full-context alerts, escalation that doesn't depend on someone remembering, deduplication that keeps signal at signal strength — and monitoring, RMM, helpdesk, and patching on one platform, so an alert is a starting gun rather than the first clue.
Your users will forgive an outage. They will not forgive finding out that you knew nothing — and neither will a regulator. Make detection a design decision, not a hope.
Related Resources
AlertMonitor Alert Management & On-Call Operations AlertMonitor Platform Overview Book a Demo Alert Management & On-Call Operations Resources
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.