Unattended Infrastructure Can't Watch Itself: The Server Monitoring Lesson in Fervo's 33 MW Utah Launch

This week, Google-backed geothermal developer Fervo Energy brought 33 MW of its Utah project online — the first slice of an estimated 4 GW of geothermal potential, with 100 MW targeted by New Year's and half a gigawatt by 2028. Hyperscalers like Google are anchoring these projects because data centers need firm, around-the-clock power, not intermittent capacity.

Here's the detail that should matter to every sysadmin, IT manager, and MSP tech reading this: nobody stands next to these plants. A geothermal site in the Utah desert is unattended, mission-critical infrastructure. It runs 24/7, failures are expensive, and the entire operation depends on sensors, thresholds, telemetry, and automated alerting that puts the right engineer on the problem in seconds.

Now think about your environment. The Hyper-V host running your ERP. The file server whose D: volume has been creeping toward full for three weeks. The domain controller in a branch office nobody has visited since the pandemic. The nightly backup scheduled task that has been failing quietly since the second Tuesday of last month. Like that geothermal plant, your infrastructure runs unattended. The only question is whether your monitoring tells you before your users do.

For too many IT teams, the honest answer is no. And that's an architecture problem, not a staffing problem.

The Problem: Stitched-Together Monitoring Fails in the Gaps

Most IT departments and MSPs run monitoring as a Frankenstein stack:

• A server agent from one vendor polling every 5–15 minutes
• A standalone uptime tool pinging HTTP endpoints
• A separate application monitor for the line-of-business apps
• A helpdesk that has no idea what any of those tools are saying
• For MSPs, an RMM (ConnectWise, NinjaOne, N-able) that overlaps half of the above and duplicates the alerts

Each tool works in isolation. The outages happen in the seams between them.

Consider a scenario every sysadmin will recognize. Friday, 4:47 p.m.: log growth from a runaway job starts filling the data volume on your SQL server. The legacy agent checks disk every 15 minutes, and the threshold is set at 95% because a 90% alert was "too noisy" — so somebody raised the threshold instead of fixing the noise. The drive crosses 95% Saturday morning and SQL starts throwing errors. Your uptime tool — watching the HTTP endpoint of the ERP front end — stays green because the web server is fine. The first human signal arrives Monday, 8:52 a.m., as a finance ticket: "ERP feels slow." By the time a tech remotes in and finds the full disk, you've logged roughly 40 hours of degraded service, blown a month-end close, and produced an incident review whose punchline is brutal: the data existed the whole time. Nobody was looking at the right metric, at the right interval, in one place.

The costs compound from there:

• Detection time dominates MTTR. When users are your monitoring, add 20–60 minutes to every incident — and accept that low-visibility failures (a stuck scheduled task, a degrading RAID volume) may never get reported at all.
• Alert fatigue silences the alarm that matters. Three tools alerting on the same host produce 60+ notifications overnight. Techs tune out, rules get loosened, thresholds get raised — and then the real disk-full alert is the one you muted.
• MSPs drown in swivel-chair work. Twelve browser tabs across five tools to support one client. Every triage starts with "which console do I even open?"
• SLA reporting becomes fiction. Monitoring says the service was down 47 minutes. The helpdesk says the ticket was handled within SLA — because the ticket was opened 35 minutes after the alert landed in a shared mailbox nobody watches. Which number does the client believe? Neither, after a while. And once techs stop trusting the tools, 2 a.m. pages get snoozed.

Why do these gaps exist? Because the stack was assembled, not designed. The agent polls on intervals because it was architected years ago around scarce bandwidth. The uptime tool watches endpoints because that's all it was ever built to watch. The helpdesk only knows what a user types into a portal. There is no shared event stream, so correlation — "the backup failed AND the disk is climbing AND the service restarted three times" — has to happen inside a human's head, at 2 a.m., from memory. That's not a process you can train your way out of.

How AlertMonitor Closes the Gap

AlertMonitor was built on the premise that monitoring, alerting, helpdesk, RMM, and patching are one system, not five products. One agent, one pane of glass, one alert stream covering servers, services, applications, Windows workstations, and scheduled tasks — in real time.

What that changes concretely:

• Real-time detection instead of 15-minute polls. Disk crosses 90%, a critical Windows service dies, a scheduled task returns a nonzero result — the alert fires in seconds, not on the next poll cycle.
• Intelligent alerting that respects on-call sanity. Thresholds and baselines tuned per volume and per service, dependency suppression (a dead core switch doesn't trigger 30 "server down" pages for the machines behind it), and escalation chains that reach the right person without mailing the whole distribution list.
• Monitoring that talks to the helpdesk. A critical alert automatically opens a ticket with the device, metric history, and severity attached. Acknowledging the ticket acknowledges the alert. Your SLA report finally has one timeline, from detection to resolution, instead of two systems telling different stories.
• RMM in the same window. The alert screen has a remote session button. You go from paged to fixing without hunting for credentials, a client install, and the right console.
• Patching connected to the incident. The server you just remoted into shows its patch state and pending reboots — because "the server rebooted itself at 2 a.m." and "it's three months behind on updates" are usually the same incident.

The workflow, before and after:

Old way: User ticket at 8:52 → triage → open the uptime tool → open the agent console → RDP in → discover the disk filled up Saturday → reconstruct the timeline from memory → no defensible SLA data.

AlertMonitor: Metric breach at 4:47 → alert and auto-created ticket within seconds → on-call paged → remote session straight from the alert → script clears the log bloat or extends the volume → resolved with a complete timeline. Total human involvement: a few minutes, at the moment it mattered.

Practical Steps You Can Take Today

1. Audit your alert paths. For each critical system, write down: which tool detects it, at what interval, at what threshold, who gets paged, and whether an event becomes a ticket automatically. The blanks in that list are your incident blind spots.

2. Set progressive disk thresholds per volume — and check reality right now. System volumes, log volumes, and data volumes behave differently. A good baseline is 80% warning, 90% critical, plus rate-of-change alerting ("this volume is full in ~72 hours"). Meanwhile, get an honest picture of disk headroom across your Windows estate:

$servers = "DC01","FILE01","SQL01","APP01"
Get-CimInstance -ClassName Win32_LogicalDisk -Filter "DriveType=3" -ComputerName $servers |
    Select-Object SystemName, DeviceID,
        @{n='SizeGB';e={[math]::Round($_.Size/1GB,1)}},
        @{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

3. Stop trusting "Running" as a status. A service can report Running and still be wedged, and an auto-start service that died overnight may have exhausted its three recovery attempts before anyone looked. Verify your critical services are running and configured to start:

$critical = "MSSQLSERVER","DNS","Netlogon","W32Time"
Get-Service -ComputerName SQL01 -Name $critical |
    Select-Object Name, Status, StartType

Then make that check continuous, not a one-time audit:

$action  = New-ScheduledTaskAction -Execute "PowerShell.exe" -Argument "-NoProfile -File C:\Scripts\Test-CriticalServices.ps1"
$trigger = New-ScheduledTaskTrigger -Once -At (Get-Date) -RepetitionInterval (New-TimeSpan -Minutes 5)
Register-ScheduledTask -TaskName "CriticalServiceCheck" -Action $action -Trigger $trigger -RunLevel Highest

4. Watch your scheduled tasks — the silent failure capital of Windows infrastructure. Nightly backups, certificate renewals, sync jobs: they fail quietly, and you find out at month-end. Catch nonzero results from the last 24 hours:

Get-ScheduledTask -CimSession FILE01 |
    Where-Object { $_.State -ne 'Disabled' } |
    ForEach-Object {
        $info = $_ | Get-ScheduledTaskInfo
        if ($info.LastTaskResult -ne 0 -and $info.LastRunTime -gt (Get-Date).AddDays(-1)) {
            [PSCustomObject]@{
                Server  = 'FILE01'
                Task    = $_.TaskName
                LastRun = $info.LastRunTime
                Result  = $info.LastTaskResult
            }
        }
    }

5. Same discipline on Linux — one line for disk headroom:

df -h -x tmpfs -x devtmpfs | awk 'NR>1 && substr($5,1,length($5)-1)+0 >= 85 {print $1, $5, $6}'

6. Wire monitoring into the helpdesk — no shared mailboxes. A critical alert must create a ticket or page a human, every single time. If your current stack needs custom middleware to make that happen, that's your integration debt coming due.

7. Cut noise before you cut thresholds. Add dependency suppression so a dead core switch doesn't page you for all 30 machines behind it, and baseline your metrics so alerts fire on deviation, not just static limits. The goal: every page is actionable. Fervo doesn't staff humans to watch thousands of sensor channels around the clock; it engineers thresholds, baselines, and escalation so the alerts that do fire are the ones worth waking up for.

The Takeaway

Fervo is proving that unattended, mission-critical infrastructure can run safely at 33 MW and scale toward 4 GW — because the telemetry, thresholds, and alerting were designed as one system from day one. Your servers, workstations, services, and scheduled tasks deserve the same design: one platform, one alert stream, seconds from detection to the right person. That's the difference between learning about a problem from a dashboard and learning about it from a ticket that says "the ERP is slow."

Related Resources

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