Oracle is one of the best-funded infrastructure builders on the planet. And according to The Register, its planned AI datacenter in Wisconsin — targeted to start delivering to customers in 2027 — is at risk of slipping, because the one thing that facility absolutely cannot run without is still pending: the grid connection, waiting on regulatory approval.
Sit with that for a second. A flagship datacenter program with effectively unlimited budget, top-tier engineers, and board-level attention is stuck on a dependency that was visible from day one and produces no alerts until it becomes a crisis.
Now think about your environment.
The file server volume that's been creeping up 2 GB a week since the marketing team started hoarding video files. The UPS in the branch office closet whose battery degraded six months ago — nobody noticed because the vendor's monitoring console emails a monthly PDF nobody opens. The PDU feeding your Hyper-V cluster sitting at 91% load with no headroom for a failover event.
None of these are outages today. All of them are Oracle's Wisconsin problem at smaller scale: a capacity dependency that everyone will find out about at the worst possible moment, because nothing in the toolchain escalates trajectory — only failure.
And when it does fail, the question that decides whether it's a 20-minute fix or a career-defining Saturday is simple: who got paged, with what context, and how long ago?
Why "Disk 90% Full" Alerts Are the Wrong Design
Most monitoring stacks in mid-market IT are built on a model that hasn't changed since the Nagios era: poll a check every five minutes, compare against a static threshold, fire an alert when it crosses.
That model has a fatal flaw for capacity problems: it alerts on state, not trajectory.
Consider what actually happens:
- A SQL Server transaction log starts growing after an application change pushes more writes. At 85% full, silence. At 89%, silence. The night it crosses 90%, someone's phone buzzes at 2:07 AM — even though the growth rate made this predictable three weeks earlier.
- Meanwhile, the disk that fills in 20 minutes because of a runaway log or a misconfigured backup job? The 5-minute poll might catch it — or might page after the disk is already full and SQL Server is already down.
So your alerting is simultaneously too early (predictable creep pages someone at night) and too late (fast failures page after the outage has already started). Both directions burn trust in the monitoring tool — and a team that doesn't trust its monitoring stops acting on it.
The Alert Storm Problem Nobody Budgets For
Capacity is only half of it. The other half is what happens when something actually breaks.
A core switch port starts flapping. Every downstream device drops. Your RMM fires offline alerts for 60 endpoints. Your SNMP monitoring fires device-timeout alerts. Your helpdesk collects 14 tickets saying "is the network down?" Your on-call tech gets 200+ notifications in 10 minutes, swipes most of them away, and very nearly swipes away the one that matters.
One root cause. Hundreds of alerts. Zero deduplication — because the RMM (Ninja, ConnectWise, Datto — pick yours), the network monitor (PRTG, LibreNMS, SolarWinds), and the helpdesk were bought separately, at different times, for different problems, and none of them share an incident model.
This is why the gaps exist in almost every IT shop:
- Siloed architecture. Endpoint health lives in the RMM. Network lives in the SNMP tool. The UPS lives in APC PowerChute or Eaton's console. The firewall has its own dashboard. Each tool escalates into its own silo — or into the same shared mailbox, which amounts to the same thing.
- Alerts without context. "Volume C: on SVR-APP-03 at 91%" doesn't say which client, what the baseline was, what changed last week, or what healthy looks like. Triage becomes archaeology.
- Escalation by email alias. alerts@company.com is not an on-call rotation. There's no acknowledgment tracking, no re-escalation on no-response, no business-hours versus after-hours routing.
What This Actually Costs
A scenario every MSP tech will recognize: Friday, 6:15 PM. A client's Hyper-V host goes dark because the building lost power for 11 minutes and the UPS battery — degraded, unmonitored outside the vendor console — gave up at minute four. The server-down alert landed in a shared mailbox. The first human sees it Sunday morning. Now you're restoring from backup, explaining data loss to a client, and having a very awkward QBR.
The measurable costs:
- Downtime length. A disk issue that should have been a planned 30-minute cleanup becomes an unplanned crash, a lost weekend, and a restore-from-backup.
- Ticket volume. Users report problems before monitoring does, which means your helpdesk absorbs the discovery function your monitoring stack was bought to perform.
- SLA reporting fiction. Response-time data lives in the helpdesk, alert data lives in the monitoring tool, and nobody can prove when the team knew versus when they acted.
- Burnout. Nobody quits over one bad night. They quit over the tenth 2 AM page a trend line would have prevented — and over the alerts they'd learned to ignore on the night the real one came through.
How AlertMonitor Treats Capacity as an Alerting Problem
AlertMonitor was designed around a specific insight: alert fatigue isn't a volume problem — it's a signal quality problem. The fix isn't fewer checks. It's alerts that carry meaning and reach the right person at the right time.
Here's what changes concretely:
Trending instead of thresholds. Capacity metrics — disk, memory, bandwidth — are evaluated on growth rate, not just current value. "Volume will be full in ~12 days at current growth" generates a warning during business hours and lands as a planned task, not a page at 2 AM the night it hits 90%.
Smart deduplication. When a root cause produces a cascade, AlertMonitor correlates the child alerts into one incident with full context, instead of burying your on-call tech under 200 notifications.
Context on every alert. Device, client, what changed, and what healthy looks like are attached to the alert itself. Triage starts with answers, not questions.
Multi-level on-call routing. Escalation policies route by severity and category: capacity warnings go to the business-hours ticket queue; a UPS on battery or a host down pages the actual on-call tech — with acknowledgment tracking and automatic re-escalation if nobody responds.
Maintenance window suppression. Planned patching and migrations don't manufacture false pages, so when something fires during a window, it's real.
Power and environmental monitoring in the same pipeline. UPS units, PDUs, and temperature sensors poll via SNMP into the same alert engine as your servers. A battery at 60% health escalates like any other critical — because it is one.
One system of record. Because monitoring, RMM, helpdesk, and patching share a platform, the capacity alert becomes a ticket with the device attached, the tech remotes in from the alert, and the SLA report is real — because the timestamps live in one place.
The workflow difference, concretely:
- Old way: Eaton console sends monthly PDF → shared mailbox → nobody reads it → building loses power → server down → someone notices Sunday → four tools open to triage → angry client.
- AlertMonitor way: battery health trend alert fires Tuesday 10 AM → deduplicated and routed to the on-call tech with device, client, and severity → acknowledged in 2 minutes → ticket created → remote session → battery replacement scheduled. Eight minutes total, zero downtime.
Practical Steps You Can Take This Week
1. Audit your alert-to-action ratio. Pull last month's alerts and count how many resulted in action. If it's under 10–15%, you have a signal quality problem, and adding another tool won't fix it.
2. Find every power and environmental device you own. UPS units, PDUs, temperature sensors — in your office, your server room, and every client site if you're an MSP. If any of them report only to a vendor console, treat them as unmonitored. This is the exact class of dependency stalling a flagship datacenter build.
3. Start measuring trajectory, not just state. Even before trending alerting is in place, a simple daily snapshot gives you a days-to-full estimate:
# disk-trend.ps1 — run daily via Task Scheduler; estimates days-to-full per volume
$servers = @("FS01","SQL01","HV01","APP01")
$stateFile = "C:\Monitor\disk-snapshot.csv"
$snapshot = foreach ($srv in $servers) {
Get-CimInstance Win32_LogicalDisk -Filter "DriveType=3" -ComputerName $srv |
Select-Object @{n='Server';e={$srv}}, DeviceID,
@{n='FreeGB';e={[math]::Round($_.FreeSpace/1GB,2)}}
}
if (Test-Path $stateFile) {
$prev = Import-Csv $stateFile
foreach ($disk in $snapshot) {
$old = $prev | Where-Object { $_.Server -eq $disk.Server -and $_.DeviceID -eq $disk.DeviceID }
if ($old) {
$burnGBPerDay = [math]::Round(($old.FreeGB - $disk.FreeGB), 2)
if ($burnGBPerDay -gt 0 -and $disk.FreeGB / $burnGBPerDay -lt 14) {
Write-Warning ("{0} {1}: ~{2} days until full (free {3} GB, burning ~{4} GB/day)" -f `
$disk.Server, $disk.DeviceID, [math]::Round($disk.FreeGB / $burnGBPerDay,0), $disk.FreeGB, $burnGBPerDay)
}
}
}
}
$snapshot | Export-Csv $stateFile -NoTypeInformation
4. Detect dirty power events on your Windows servers. Event ID 41 (kernel-power) and 6008 tell you a machine lost power without a clean shutdown — often the only trace that a UPS failed before anyone thinks to check it:
# Find unexpected power-loss shutdowns in the last 30 days
Get-WinEvent -FilterHashtable @{LogName='System'; Id=@(41,6008); StartTime=(Get-Date).AddDays(-30)} `
-ErrorAction SilentlyContinue |
Select-Object TimeCreated, Id, @{n='Detail';e={($_.Message -split "`n")[0]}} |
Format-Table -AutoSize
5. Verify your UPS fleet directly. If your UPSes speak SNMP, poll them. If this command fails or returns stale data, that device is effectively dark:
# Poll UPS health over SNMP (adjust community string and address per device)
snmpget -v2c -c public 192.0.2.50 \
UPS-MIB::upsBatteryStatus.0 \
UPS-MIB::upsEstimatedChargeRemaining.0 \
UPS-MIB::upsSecondsOnBattery.0
6. Re-tier your escalation policies. Warnings and trends should never wake anyone up — they should be waiting as tickets at 9 AM. True criticals (host down, UPS on battery, service failed on a production system) should page a named human, with re-escalation if unacknowledged within 5–10 minutes. If your current policy is "email the shared mailbox," you don't have an escalation policy — you have a suggestion box.
7. Put maintenance windows to work. Every planned change should suppress alerts for the affected scope. If your techs have learned to ignore pages during patch weekends, suppression isn't configured — and your monitoring tool is actively training your team to ignore it.
The Oracle story is a useful humiliation for the entire industry: the biggest infrastructure project in the news is stuck on the same failure mode as the branch-office closet UPS — a dependency that was always visible and never escalated. The difference between a year-long delay and an eight-minute fix isn't budget. It's whether your alerting sees trajectory, deduplicates noise, and puts the right signal in front of the right person.
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.