Forty years ago, one of the most ambitious digital projects in history nearly died — not because the data was lost, but because every practical path to reach it had rotted away. If you run infrastructure for a living, that failure mode should sound uncomfortably familiar. Your monitoring stack can detect a filling disk in 60 seconds. But actually touching that server? That takes three other tools, two logins, and a hostname that doesn't match between them. The alert is modern. The access is the problem.
Forty Years On, the Lesson Still Stings
In 1986, the BBC marked the 900th anniversary of the original Domesday Book with a project that looked like science fiction: a national survey of British life — maps, tens of thousands of photographs, statistics, video walks, first-person accounts — delivered on 12-inch laserdiscs and driven by BBC Master microcomputers. It was arguably the most advanced multimedia project of its decade.
Then the future arrived and left it behind. Within about fifteen years, the discs were becoming unreadable, the custom hardware was failing, and this national treasure was closer to extinction than the vellum original it celebrated. Rescuing it took years of reverse engineering. Recently, the Centre for Computing History brought together the people who built the project and the people still keeping it alive — four decades later, still fighting to make the data reachable.
Read that again as an IT manager: the failure wasn't lost information. It was inaccessible information. Everything existed, but the tooling to act on it had crumbled, and the knowledge of how to reach it lived in a handful of specialists' heads. Now map that onto your own stack.
The Swivel-Chair Tax, Itemized
A typical mid-size IT team or MSP runs something like this:
- Monitoring: PRTG, Zabbix, Nagios, or Datadog — excellent at telling you something is wrong.
- RMM: ConnectWise ScreenConnect, NinjaOne, Datto RMM, or Action1 — the only thing that can actually act on an endpoint.
- Helpdesk: ServiceNow, Freshservice, HaloPSA, or ConnectWise PSA — where the record of what happened is supposed to live.
- Patching: WSUS, Intune, or the RMM's patch module — a fourth console with its own compliance view.
Four tools. Four inventories. Four timelines. Often three or four agents installed on the same endpoint, each reporting to a different place. And every one of those agents knows something the others don't.
The moment an alert fires, the technician's real work begins — and almost none of it is fixing the problem:
- Read the alert in the monitoring console. Note the hostname — which, of course, doesn't match the RMM's inventory name.
- Hunt for the device in the RMM. Wait for the agent to check in.
- Open a remote session. Discover the cached credential isn't the local admin one.
- Fix the thing. Close the session.
- Separately, reconstruct what happened and type it into the helpdesk ticket — usually hours later, from memory, or never.
Steps 1 through 5 routinely add 25–45 minutes to incidents where the actual fix took four. Run the math for a team handling 30–50 actionable alerts a day: that's one to two full-time engineers' worth of capacity burned on context-switching alone. Nobody budgets for that line item. Everyone pays it.
And the Domesday pattern shows up in your environment too. There's always that one legacy box — the production-floor workstation wired to a serial device, the server reachable only from a specific jump host. The knowledge of how to get into it lives in one senior tech's head. That's your laserdisc. When that person is on holiday and the box falls over at 2 a.m., you'll be reverse-engineering your own infrastructure while users wait.
Why the Gaps Exist
Not because anyone chose badly — because the categories were built a generation apart, for different jobs. Monitoring grew out of server-room up/down checks: SNMP, ping, port probes. RMM grew out of MSP endpoint management. Helpdesk grew out of ITSM. The "suites" that claim to cover all three usually got there by acquisition: three codebases, three agents, three databases, and an API integration bolted on where a shared data model should be.
The result is the Domesday pattern at the process level. Each tool holds part of the truth, and the connective tissue between them is a human being with a mouse. When that human is asleep, out sick, or simply fatigued at 2 a.m., the connective tissue fails — and the incident runs long.
Here's the part that should genuinely worry every IT manager: the swivel chair also destroys your audit trail. When techs get tired of the tab dance, they quietly start using raw RDP and SSH — "I'll just do it quickly." The work still happens. The record doesn't. Actions that were taken but never captured are your own private Domesday archive, and you'll be excavating them at the next post-mortem trying to work out why the service is suddenly running. Your SLA reporting has the same disease: the monitor knows when the alert fired, the helpdesk knows when the ticket closed, and the truth in between lives in nobody's system.
How AlertMonitor Collapses the Stack
AlertMonitor was built on the opposite assumption: infrastructure monitoring, RMM, helpdesk, patching, and network topology belong in one platform — one agent, one inventory, one timeline. Concretely, what changes:
- Alert to action without switching tools. An alert fires; you click through to the device. You land on a device page showing its monitoring history, patch state, open tickets, and the action bar: open a remote session, run a script, push software. The RMM isn't a separate product sitting next to the monitor. It's the same console.
- Scripts run across device groups. Select a group — a client, a site, "all SQL servers" — and run a script against every member at once. No per-device sessions, no for-loop of remote desktop windows.
- Script results feed back into the monitoring data. This is the part that changes outcomes. The remediation you ran isn't a private side event; its output lands on the same timeline as the alert that triggered it. Alert → action → result, in one record, forever.
- Helpdesk in the same pane. The user's ticket, the device's health, and the fix you applied are one view. The documentation writes itself instead of being retyped from memory at 6 a.m.
The Workflow, Side by Side
The old way: 2 a.m. disk alert → open the monitor → identify the server → open the RMM → hunt for the device → remote in → clean up the volume → back to the monitor to confirm the alert clears → next morning, reconstruct the whole thing into a ticket. Total: 40+ minutes, two context resets, and a documentation step that usually loses.
The AlertMonitor way: 2 a.m. disk alert → click the alert → the device page opens with full context and the action bar → run the cleanup script → script output and alert clearance appear on the same timeline, attached to the ticket. Total: under five minutes, zero tab switches, audit trail complete before you're back in bed.
For an MSP, multiply the difference by every client. A patch compliance sweep or a fleet-wide script that used to be an afternoon of connecting to machines one at a time becomes a single run against a device group, with every result visible in one place.
Practical Steps You Can Take Today
1. Measure your swivel-chair tax. Pick your five most common alerts and count the tools and steps between "alert received" and "fix verified." Multiply by daily volume. That number is your business case.
2. Turn recurring checks into scripts. The disk-full alert is the classic. Here's a sweep you can run against your Windows fleet from the same console you monitor with:
# Report servers with less than 15% free space on fixed drives
$servers = "FS01","FS02","SQL01"
Get-CimInstance Win32_LogicalDisk -Filter "DriveType=3" -ComputerName $servers |
Select-Object PSComputerName, DeviceID,
@{n='FreeGB'; e={[math]::Round($_.FreeSpace/1GB,1)}},
@{n='TotalGB'; e={[math]::Round($_.Size/1GB,1)}},
@{n='FreePct'; e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
Where-Object { $_.FreePct -lt 15 } |
Format-Table -AutoSize
3. Script the fix, not just the check. A service watchdog that outputs its own timestamped record — exactly what you want feeding back into your monitoring timeline:
# Verify the Print Spooler and restart with an auditable output
$svc = Get-Service -Name "Spooler" -ErrorAction SilentlyContinue
if ($null -eq $svc) {
"Spooler not found on $env:COMPUTERNAME"
} elseif ($svc.Status -ne 'Running') {
Start-Service -Name "Spooler"
"{0} | Spooler was {1} - restarted" -f (Get-Date -Format 'yyyy-MM-dd HH:mm:ss'), $svc.Status
} else {
"{0} | Spooler OK (Running)" -f (Get-Date -Format 'yyyy-MM-dd HH:mm:ss')
}
4. Check patch compliance without opening a fourth console. This runs locally on any Windows endpoint your agent can reach:
# List pending Windows updates on the local machine
$session = New-Object -ComObject Microsoft.Update.Session
$searcher = $session.CreateUpdateSearcher()
$pending = $searcher.Search("IsInstalled=0 and Type='Software'")
"[$env:COMPUTERNAME] Pending updates: $($pending.Updates.Count)"
$pending.Updates | ForEach-Object { " - $($_.Title)" }
5. Same discipline on Linux endpoints:
# Flag any filesystem over 85% full, then make sure nginx is alive
df -h --output=source,pcent,target | awk '$5+0 > 85 {print "DISK WARNING:", $0}'
systemctl is-active --quiet nginx || { systemctl restart nginx; echo "nginx restarted"; }
6. Push at scale with device groups, not per-device sessions. Once a remediation script is proven on one machine, attach it to the device group it protects — a client, a site, a server role — and run it everywhere from one place. That's the difference between fixing one print server and never touching print servers again.
7. Let the timeline do the documentation. Audit one week of incidents and verify that every action — manual or scripted — landed on the device record and the ticket automatically. If your techs are still writing post-incident notes from memory, the stack is the problem, not the staff.
Stop Building Your Own Domesday
The tragedy of the BBC Domesday Project isn't that bright people made bad choices in 1986 — they made the best choices available with the technology of the day. The tragedy is that reachability was never part of the design, and it took a rescue mission decades later to fix. Forty years on, a gathering of the project's original engineers and its preservationists at the Centre for Computing History is both a celebration and a warning.
Your monitoring data, your endpoints, your remediation history: they're only as valuable as your ability to act on them in the moment, and only as trustworthy as your record of what was done. If acting requires a second tool, a third login, and a fourth console, you've built a small Domesday of your own — brilliant visibility, crumbling access.
Collapse the stack. One console, one timeline, one agent. Your 2 a.m. self will thank you.
Related Resources
AlertMonitor RMM & Remote Management
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.