The Disk Hit 90% on Saturday. You Heard About It Monday: Fixing Fragmented Infrastructure Monitoring

A recent InfoWorld article, "Screencasting in the AI era," tells a story every IT professional will recognize. The author spent years producing screencasts and never found a tool that worked the way he actually works — no conventional tool gave him easy, precise, frame-accurate control over cuts, annotations, pauses, and narration. So when the AI era made rebuilding practical, he stopped tolerating the compromise and built the editor he had always wanted.

Strip away the subject matter and that is the infrastructure monitoring story too. We have tolerated monitoring stacks that force us to adapt to them — an agent here, an uptime checker there, a third tool for applications, a fourth for tickets — long past the point where we should have demanded tooling built around how IT teams actually operate.

Look at a typical mid-size IT shop or MSP right now: a Nagios or Zabbix box checking ping and SNMP, UptimeRobot or Pingdom watching public endpoints, ConnectWise Automate or NinjaOne covering endpoints, PRTG or SolarWinds on the network, and a helpdesk that mostly learns about incidents from users. Five tools. Five alert streams. Zero correlation. The result is predictable: a disk fills on Saturday night, and the first signal anyone gets is a Monday-morning ticket that reads "the file server is slow."

This post breaks down why these assembled-not-designed stacks fail, what a unified alternative looks like in practice, and the exact steps — including scripts you can run today — to close the gaps before the next weekend incident.

The Problem in Depth: A Stack Assembled, Not Designed

Nobody chose this stack. It accumulated. The Nagios server went in back in 2015. The uptime checker was a quick SaaS signup when the website started mattering. The RMM arrived with client growth. The helpdesk was procured on a different budget line entirely. Each decision was reasonable. Together, they are a liability.

Every tool has its own threshold logic and its own alert path. The RMM flags disk at 90% as a "warning" that emails a shared mailbox. The legacy monitor does not check disk at all. The uptime checker only knows whether a TCP port answers. Thresholds drift, nobody owns them, and after 5pm on Friday the shared mailbox is a graveyard.

Alerts and impact never correlate. When the accounting application's Windows service crashes, three systems react independently: the HTTP check reports "endpoint down," the event log collector records a Service Control Manager error, and the helpdesk takes a ticket that says "can't open invoices." Your technician triages with three browser tabs and no linkage between them.

Context lives somewhere else. To act on a single alert, a technician swivel-chairs: read the alert in the monitoring tool, remote into the server with the RMM, check patch status in a fourth console, then create the ticket in a fifth. Every hop loses context and burns minutes — and in an incident, minutes are the SLA.

Blind spots are structural, not accidental. Scheduled tasks, Windows services on "unimportant" servers, printers, the backup drive that fills with VSS shadow copies every third weekend — each tool covers its own silo, and incidents live precisely in the seams between silos.

What It Costs, in Numbers a Manager Recognizes

• Detection time measured in hours, not seconds. If your sensor is a user ticket and users trickle in at 8:30, a failure at 22:00 on Saturday stays invisible for more than 10 hours. For mid-size organizations, unplanned downtime is routinely costed at thousands of dollars per hour — and MSPs pay it twice, in firefighting labor and client churn.
• Ticket volume inflation. Every missed alert becomes one to five duplicate tickets as different users report the same failure. Every context-free ticket takes longer to resolve, so helpdesk metrics look worse than the underlying infrastructure deserves.
• SLA reporting is fiction. Monitoring data lives in one system, tickets in another. You cannot compute true time-to-detect or time-to-respond, so you report what the helpdesk saw — not when the service actually died. Clients and auditors notice.
• Burnout with a specific shape. It is not the 2am page that demoralizes a good sysadmin. It is the 2am failure that did not page anyone and was discovered at 9am by a user. Nothing erodes trust in a monitoring investment faster.

Here is the scenario in full: Friday 18:47, a file server's system drive starts filling — backup logs plus shadow copies growing unchecked. The legacy monitor polls disk every 15 minutes with a 95% threshold that never fires before the volume hits 100% at 23:12. The SQL Express instance behind the inventory app on the same box stops writing. The weekend stays quiet. Monday 08:26, the first ticket: "Files won't save." By 09:10 there are five tickets, an operations manager in your queue, and a cleanup that eats the morning. Customer-visible impact: roughly 58 hours. With correct thresholds and alert routing, detection would have taken seconds.

How AlertMonitor Solves This: One Agent, One Alert Stream, One Console

AlertMonitor is the "editor I always wanted" answer for infrastructure monitoring — a platform built around the operator's workflow instead of a stack you bend yourself around.

A single agent covers the whole stack. Servers, services, applications, Windows workstations, scheduled tasks, and network devices — all monitored in real time from one agent in one platform. You do not stitch together a server agent, a separate uptime tool, and a third application monitor, because they are one product with one data model.

One intelligent alert stream. When a disk crosses 90% or a critical Windows service crashes, AlertMonitor evaluates severity and pages the right person within seconds — push, SMS, email, and escalation chains — not a shared mailbox. Because monitoring, RMM, helpdesk, patch management, and topology mapping share the platform, the alert arrives with context attached: the host, its patch state, the services running on it, and what else on the network map depends on it.

Alert to resolution without the swivel-chair. The old workflow: alert email → log into the monitoring portal → open the remote-access tool → check the patch report elsewhere → create the ticket → update the ticket → reconcile timelines afterward. In AlertMonitor: the alert fires with full context → the technician acts from the same console (remote session, service restart, patch check) → the alert is already linked to a ticket with a complete timeline → SLA reporting is automatic, because detection time and response time live in the same system.

What changes in practice. Detection drops from tens of minutes — or hours, when users are the sensor — to seconds. Duplicate tickets disappear because one incident generates one alert-linked ticket. Hours lost per technician to tool-switching collapse. For an MSP, the NOC view stops being twelve tabs across five products and becomes one queue with every client in it, filterable by severity and SLA risk.

Practical Steps: Close the Gaps This Week

1. Inventory what each tool actually monitors. List every monitored element per tool: which disks have thresholds, which services are watched, whether scheduled tasks are covered at all. The seams you find are where your incidents have been hiding.

2. Set thresholds that fire early and route to a human. Disk alerts at 85–90% with escalation — not 95% into a mailbox. Critical-service-failure alerts that page, not just log. Verify that a person is on the other end of every escalation chain.

3. Validate coverage with real checks. These scripts are useful ad hoc today, and the same logic is what a unified monitoring platform should be running continuously:

Disk free space across servers — find the drives that will page you next month:

$servers = "FS01","SQL01","DC01","APP01"
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='FreePct';e={[math]::Round(($_.FreeSpace/$_.Size)*100,1)}} |
  Where-Object { $_.FreePct -lt 15 } |
  Sort-Object FreePct | Format-Table -AutoSize

Critical service check with restart — catching what an HTTP uptime checker cannot see:

$critical = @("MSSQLSERVER","Spooler","wuauserv")
foreach ($name in $critical) {
  $svc = Get-Service -Name $name -ErrorAction SilentlyContinue
  if ($svc -and $svc.Status -ne 'Running') {
    Write-Warning "$name is $($svc.Status) on $env:COMPUTERNAME - attempting start"
    Start-Service -Name $name
  }
}

Patch staleness across servers — patch state belongs next to your alerts, not in a separate console:

Invoke-Command -ComputerName "FS01","SQL01","DC01" -ScriptBlock {
  $last = Get-HotFix | Where-Object InstalledOn |
          Sort-Object InstalledOn -Descending | Select-Object -First 1
  [PSCustomObject]@{
    Server    = $env:COMPUTERNAME
    LastPatch = $last.HotFixID
    Installed = $last.InstalledOn
    DaysOld   = if ($last.InstalledOn) { ((Get-Date) - $last.InstalledOn).Days } else { 999 }
  }
} | Sort-Object DaysOld -Descending | Format-Table -AutoSize

The same two failure modes on Linux — full filesystems and dead units:

# Warn on any filesystem >= 90% used
df -h -x tmpfs -x devtmpfs | awk 'NR>1 {gsub(/%,"",$5); if ($5+0 >= 90) print "DISK WARNING:", $1, $5"%", $6}'

# List failed systemd units
systemctl list-units --state=failed --no-pager

4. Make the alert stream the single source of truth. When monitoring, patch state, remote actions, and tickets share one platform, your SLA report stops being an Excel merge of three CSV exports — it becomes a filter.

5. Retire the redundant tools. Every duplicate tool you decommission removes one alert path, one login, one renewal, and one more place where an incident can hide unnoticed.

The InfoWorld piece lands on a simple idea: when the tooling finally matches the work, the work gets faster and better. Infrastructure monitoring is overdue for that reset. Your servers are already telling you everything — the only question is whether your stack lets you hear it before a user does.

Related Resources

AlertMonitor Infrastructure & Server Monitoring AlertMonitor Platform Overview Book a Demo Infrastructure & Server Monitoring Resources