The Register's recent piece on reviving Jef Raskin's three laws of software — and the flood of angry NeoVim users it references — proves something every IT pro already knows: people who operate software for a living care intensely about whether a tool respects their time, their attention, and their work. Raskin, who led the original Macintosh project, framed his philosophy in two cardinal rules: a computer shall never harm your work, and a computer shall never waste your time.
Now hold your monitoring stack up against those rules.
The disk that filled to 100% while your uptime dashboard showed "all systems green"? That harmed your work. The 2:14 a.m. page for a transient blip that self-resolved? That wasted your time. The MSP tech with twelve tabs open across five consoles — an RMM, a standalone ping checker, an app monitor, a helpdesk, a patch report — is being failed on both counts, every single shift.
Duty of care isn't just an application-development concept. If you run infrastructure, you owe your end users fast detection and honest alerting. Your monitoring platform owes your team tooling that doesn't burn them out. Most stacks in production today fail both obligations.
The Problem in Depth: The 40-Minute Outage Nobody Was Watching
Here's the scenario every sysadmin can recite from memory:
A Windows Server 2019 file server starts quietly filling its data volume on a Friday. Your uptime tool — which pings the box and checks that port 443 answers — reports healthy all weekend, because a full disk doesn't stop ICMP replies. The SQL Server Agent jobs on the same host start failing Saturday night. At 8:40 Monday morning, a user can't save a file and opens a ticket. The ticket sits in the general queue for 40 minutes before anyone triages it, and the tech who picks it up has to open the RMM, then a monitoring tool, then remote in — before anyone even knows what's wrong.
Total elapsed time from failure to human awareness: roughly 40 minutes. The monitoring platform that was supposed to catch it: never involved.
Multiply that pattern across an environment and the damage compounds fast:
- Detection by end user adds 30–60 minutes to every preventable incident. Gartner's long-cited estimate puts unplanned downtime at roughly $5,600 per minute for mid-size and enterprise organizations. Even at a tenth of that figure, a single user-discovered outage pays for a proper monitoring platform several times over.
- Alert noise trains your team to ignore pages. One failed SAN controller becomes 60 alerts across 40 devices in 15 minutes, every one flagged critical. Industry surveys consistently find that a large share of alerts are never acknowledged or acted on — not because techs are lazy, but because the tooling can't tell signal from noise.
- The helpdesk and monitoring live in different universes. Alerts go to a group mailbox; tickets go to Zendesk, Freshservice, or ConnectWise. Nobody can produce a credible SLA report, because there is no shared timeline between "the alert fired" and "the ticket closed" — the IT manager reconstructs it from two systems and a spreadsheet.
- Technician burnout is a real, measurable cost. Techs who get woken three times a month for non-issues start silencing notifications. Then they miss the real one. That's not a staffing problem — it's a tooling failure that violates Raskin's first law: the software harmed the work.
Why the gaps exist
Most "monitoring suites" are acquisitions, not architectures. The server agent came from one codebase, the uptime module from another, the patching from a third — stapled together behind one marketing website but running on separate databases, separate agents, and separate alert engines. Integration, where it exists, is usually just SMTP: the monitor emails the helpdesk ingest address, and everyone calls that a workflow. There's no shared state, no deduplication, no correlation across the stack.
Meanwhile, legacy agents only watch what they were built to watch: is the host up, is the port open. The failure modes that actually cause outages — resource exhaustion, crashed services, hung scheduled tasks, failed backups — sit outside their field of view. A ping-only check can't see a stopped Print Spooler or a hung scheduled task, and those failures don't take the box offline. The box answers ping happily all day while the business process running on it is dead.
How AlertMonitor Applies the Duty of Care
AlertMonitor was built on the same principle the article argues for: the tool exists to serve the humans operating it — and the humans depending on it downstream.
One agent, one pane of glass. Servers, services, applications, Windows workstations, scheduled tasks, and network devices monitored in real time in a single platform. No stitching a server agent to a separate uptime tool to a third application monitor, each with its own console and its own alert stream.
Detection that matches how things actually fail. Disk thresholds that warn at 85% and go critical at 92% — before the volume fills, not after. Windows service state monitoring with optional auto-restart. Scheduled task failure detection. Event log monitoring. These are the failure modes ping can't see, and they're the ones producing the 40-minute user-discovered outages.
Intelligent alerting that respects attention. Deduplication and correlation collapse alert storms into one actionable incident. Escalation policies route to the right on-call person — so when a disk hits 90% or a critical Windows service crashes, the right person is paged within seconds, not discovered by a user ticket 40 minutes later.
Helpdesk built into the same platform. An alert opens a ticket automatically, with device, metric history, and recent changes attached. The tech resolves the issue, the ticket updates, and SLA reporting finally runs off one timeline instead of a spreadsheet archaeology project between two systems.
RMM and patch management in the same console. Monitoring shows which machines came out of Patch Tuesday with pending reboots; you remediate from the same screen with remote access built in. No third tab, no CSV export, no "I'll check the patch report later."
The workflow, before and after
Fragmented stack: disk fills → nothing fires → user opens ticket → 40-minute triage delay → tech opens RMM → opens the monitoring tool → remotes in → cleans up → closes ticket → writes the post-mortem from memory.
AlertMonitor: disk hits 85% warning → trend data shows growth rate → 92% critical pages on-call with full context → one-click remote session → cleanup → ticket auto-updated and closed → complete metric timeline attached for the post-mortem.
Detection drops from 40 minutes to under a minute. Alert volume typically falls 60–80% once dedup and correlation are doing their job. And pages become worth answering — which is the entire point.
Practical Steps You Can Take This Week
1. Audit your alert stream. Count last week's alerts: total fired, total acknowledged, total that led to action. If fewer than one in five produced action, your tooling is wasting your team's time — Raskin's second law, violated nightly.
2. Add early-warning thresholds where you only have up/down today. Disk, memory, and service checks belong on every server you own. To see where you stand right now across a Windows estate:
# Report all fixed drives above 85% usage across a list of servers
$servers = Get-Content "C:\ops\servers.txt"
Get-CimInstance -ComputerName $servers -ClassName Win32_LogicalDisk -Filter "DriveType=3" |
Select-Object @{n='Server';e={$_.PSComputerName}},
@{n='Drive';e={$_.DeviceID}},
@{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,1)}},
@{n='TotalGB';e={[math]::Round($_.Size/1GB,1)}},
@{n='UsedPct';e={[math]::Round(($_.Size-$_.FreeSpace)/$_.Size*100,1)}} |
Where-Object { $_.UsedPct -ge 85 } |
Sort-Object UsedPct -Descending |
Export-Csv "C:\ops\disk-report.csv" -NoTypeInformation
3. Verify the services ping can't see. A host can answer every ping while SQL Server Agent sits dead. Check the services that actually run your business processes:
# Confirm critical services are running; restart and flag any that are not
$critical = @("MSSQLSERVER","SQLSERVERAGENT","Spooler","W32Time")
foreach ($name in $critical) {
$svc = Get-Service -Name $name -ErrorAction SilentlyContinue
if ($svc -and $svc.Status -ne 'Running') {
Write-Warning "$($svc.DisplayName) is $($svc.Status) on $env:COMPUTERNAME — restarting"
Start-Service -Name $name
} elseif (-not $svc) {
Write-Output "$name is not installed on $env:COMPUTERNAME"
}
}
4. Close the Patch Tuesday gap. Pending reboots are where patch compliance quietly dies — machines patched but never restarted are still running the old binaries. Find them:
# List servers with a pending reboot from Windows Update or servicing
$servers = Get-Content "C:\ops\servers.txt"
foreach ($server in $servers) {
$pending = Invoke-Command -ComputerName $server -ScriptBlock {
(Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update\RebootRequired") -or
(Test-Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Component Based Servicing\RebootPending")
}
if ($pending) { Write-Output "$server : REBOOT PENDING" }
}
5. Keep an eye on the Linux boxes too. Same duty of care, three lines of shell:
#!/bin/bash
# Quick health check: full disks, memory, failed systemd units
echo "=== Disks over 85% ==="
df -h --output=source,pcent,target | tail -n +2 | awk '$2+0 >= 85 {print "WARNING:", $0}'
echo "=== Memory ==="
free -h
echo "=== Failed units ==="
systemctl --failed --no-legend
6. Map your tools and cut the overlap. If your standalone uptime tool only pings and HTTP-checks while your monitoring platform already covers services, disks, and applications, it's shelfware adding a fourth alert stream. Consolidate onto one platform where every check feeds the same alert engine, the same ticket queue, and the same SLA report.
Every script above can run as a monitored check inside AlertMonitor — scheduled, alerted, escalated, and auto-ticketed on failure. That's the practical definition of duty of care: taking the script you'd run manually after an outage and making it always-on before one.
Related Resources
AlertMonitor Infrastructure & Server Monitoring
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.