Energy Bills Are the New Downtime: How RMM and Remote Management Cut Power Waste Across Your Estate

Moody's just published a forecast that should be on every IT manager's radar: the European datacenter build-out is so aggressive that server farms could consume 17% of all electricity in the Netherlands and 30% of Ireland's by 2035 — and unless governments intervene, the bill lands on businesses and consumers. The Register has the details here.

You don't run a hyperscale datacenter. But you do run servers in a closet, 300 workstations, a few branch offices — and if you're an MSP, a dozen client sites where the "server room" is a cupboard with a consumer UPS nobody has inspected since onboarding. Energy prices are already brutal, and finance has started asking the question nobody on the IT team can currently answer: where exactly is our power going, and what are you doing about it?

For most IT teams the honest answer is: nothing, because no tool in the stack owns power as a signal. Monitoring watches CPU and services. RMM pushes software. Helpdesk collects complaints. Nobody notices a failing UPS until the branch office goes dark and the first "alert" comes from an angry user on Monday morning.

That's a remote management problem. And it's exactly the gap a unified platform like AlertMonitor — monitoring, RMM, helpdesk, patching, and network topology in one console — is built to close.

The Problem: Power Is Nobody's Metric

Your monitoring stack is blind to energy and environmental signals

Typical monitoring — PRTG pings, Zabbix agents, Windows service checks — tells you a device is up or down. It does not tell you:

• The UPS in the Rotterdam branch has been reporting low battery for two weeks
• The training room's 40 PCs have been idling 24/7 since a 2019 scheduled task made someone disable sleep "to be safe"
• The server room temperature has crept past 35°C since the AC unit failed — and you'll only find out when a drive starts throwing SMART errors, at which point the damage is done

And when power does break something, you get a vague "host unreachable" at 03:14, which the on-call tech ignores because it's probably the ISP again. At 08:30 you have 27 tickets saying "the internet is down" and nothing correlates them.

The tools that could help don't talk to each other

The standard MSP stack — NinjaOne or ConnectWise for RMM, PRTG or LibreNMS for network monitoring, HaloPSA or ConnectWise PSA for tickets — was bought separately and built on separate architectures:

• The monitoring tool sees the outage but can't act on it
• The RMM shows the endpoint offline but has no context for why
• The helpdesk only knows what users typed
• No single timeline shows all three

So the night a UPS battery finally dies at a client site: monitoring emails a shared mailbox at 03:14 (nobody reads it), the RMM goes red with no explanation, users start filing tickets at 08:30, and at 09:15 a technician drives 90 minutes to discover a tripped PDU and a dead battery. Four tools, three teams, zero shared context. The actual fix took four minutes. The MTTR was eight hours, plus a tank of diesel.

The real numbers

• Idle fleets. 500 desktops idling at ~60 W around the clock burn 500 × 0.06 kW × 8,760 h ≈ 262,800 kWh/year. At €0.30/kWh, that's roughly €79,000 a year powering machines nobody is using. Most IT teams have never run this number; most finance teams would faint if they saw it.
• Avoidable truck rolls. Two hours per avoidable visit, five per tech per month, across a 10-tech MSP — that's 1,200 hours a year of pure waste, plus fuel, plus goodwill.
• Dirty shutdowns. Power blips on unprotected kit corrupt databases and filesystems. The rebuild costs a day; the credibility costs longer.
• Fictional SLA reports. When the outage record lives in the monitoring tool and the tickets live in the helpdesk, producing an accurate SLA report means manual archaeology across three exports.

These gaps exist because the tools were never integrated: monitoring polls SNMP but has no remediation capability, RMM agents have no SNMP or environmental context, and the helpdesk only sees user-reported symptoms. Unifying them isn't a nice-to-have — it's the difference between managing power and being surprised by it.

How AlertMonitor Turns Power Into a Managed Resource

AlertMonitor runs monitoring, RMM, helpdesk, patching, and network topology in one platform. That matters here because power problems are cross-domain problems — a UPS failure is simultaneously a monitoring event, a remediation job, and a ticket.

1. Power and environmental signals land in the same alert stream as everything else. AlertMonitor's SNMP monitoring covers UPS units, PDUs, and IPMI/Redfish sensors on servers, with thresholds. A UPS dropping below 50% battery becomes an alert with context — not a Monday morning mystery.

2. Alert to action, one console. The built-in RMM lets technicians remotely view and manage endpoints, run scripts across device groups, push software, and open remote sessions — in the same platform where the alert fired. When the branch server shows "offline," the tech opens a remote session, checks the UPS, and remediates. No tab-switching between a monitoring console and a separate RMM tool.

3. Script results feed back into the monitoring timeline. Automated remediations and manual technician actions both appear against the device, in sequence. When finance asks what IT did about energy, you export a timeline instead of reconstructing memory.

4. Fleet-wide power policy becomes a routine script job. Push a power plan to 400 workstations, schedule training-room shutdowns at 20:00, wake machines before a patch window — as normal script jobs on device groups, with per-device pass/fail results.

The workflow, before and after:

Old way: 03:14 "host unreachable" email → missed → 27 duplicate tickets at 08:30 → log into a separate RMM → still guessing → drive to site → fix at 11:40. MTTR: 8+ hours, one truck roll, zero audit trail.

AlertMonitor way: 03:14 UPS on-battery alert → automation runs a diagnostic script → technician opens a remote session at 03:20 → graceful shutdown of at-risk servers → alert, script output, and a linked ticket all on one timeline. MTTR: under 30 minutes, zero truck rolls, one ticket that tells the whole story.

Practical Steps You Can Take This Week

1. Find out what's actually running 24/7

Long uptime on a workstation almost always means sleep is disabled. Run this via an AlertMonitor script job against your workstation device group — results land straight in the device timeline:

# Audit devices that haven't rebooted in 30+ days — likely never sleeping
$devices = Get-Content 'C:\audit\workstations.txt'
$report = foreach ($name in $devices) {
    try {
        $os = Get-CimInstance Win32_OperatingSystem -ComputerName $name -ErrorAction Stop
        $uptime = (Get-Date) - $os.LastBootUpTime
        if ($uptime.Days -ge 30) {
            [PSCustomObject]@{
                Device     = $name
                LastBoot   = $os.LastBootUpTime
                UptimeDays = $uptime.Days
            }
        }
    }
    catch {
        Write-Warning "Unreachable: $name"
    }
}
$report | Sort-Object UptimeDays -Descending |
    Export-Csv 'C:\audit\long-uptime.csv' -NoTypeInformation

2. Enforce a sane sleep policy remotely

Push this to the offenders identified in step 1 — no desk walks, no Group Policy debugging at 17:00 on a Friday:

# Apply the Balanced plan and practical timeouts, then verify
powercfg /setactive 381b4222-f694-41f0-9685-ff5bb260df2e
powercfg /change standby-timeout-ac 30    # sleep after 30 min on AC
powercfg /change monitor-timeout-ac 10    # display off after 10 min
powercfg /change hibernate-timeout-ac 60  # hibernate after 1 h on AC
powercfg /query SCHEME_CURRENT SUB_SLEEP STANDBYIDLE

3. Monitor the UPS, not just the servers

Quick check against an APC UPS over SNMP (uses the PowerNet-MIB — adapt OIDs for Eaton or Vertiv):

#!/bin/bash
# Check APC UPS battery capacity and output status over SNMP
UPS_IP="$1"
COMMUNITY="$2"
CAPACITY=$(snmpget -v1 -c "$COMMUNITY" -Ovq "$UPS_IP" .1.3.6.1.4.1.318.1.1.1.2.2.1.0)
STATUS=$(snmpget -v1 -c "$COMMUNITY" -Ovq "$UPS_IP" .1.3.6.1.4.1.318.1.1.1.4.1.1.0)

echo "UPS ${UPS_IP}: battery ${CAPACITY}%, output status code ${STATUS}"

# APC PowerNet-MIB: status 2 = onLine. Anything else deserves an alert.
if [ "$STATUS" -ne 2 ]; then
    echo "ALERT: UPS is not on mains power."
    exit 1
fi
if [ "$CAPACITY" -lt 50 ]; then
    echo "ALERT: battery capacity below 50%."
    exit 1
fi
exit 0

Point AlertMonitor's SNMP monitoring at each UPS with thresholds on battery capacity and on-battery status. From then on, a battery problem is an alert with context — not a site visit with hindsight.

4. Wake machines before patching, let them sleep after

Keeping endpoints awake all night "just in case" is expensive. Wake on demand instead:

function Send-WakeOnLan {
    param([string]$MacAddress)
    $mac = $MacAddress -replace '[:\-]', ''
    $packet = [byte[]]::new(102)          # 6 x FF + 16 x MAC
    for ($i = 0; $i -lt 6; $i++) { $packet[$i] = 0xFF }
    for ($i = 6; $i -lt 102; $i += 6) {
        for ($j = 0; $j -lt 6; $j++) {
            $packet[$i + $j] = [Convert]::ToByte($mac.Substring($j * 2, 2), 16)
        }
    }
    $udp = New-Object System.Net.Sockets.UdpClient
    $udp.Connect([System.Net.IPAddress]::Broadcast, 9)
    [void]$udp.Send($packet, $packet.Length)
    $udp.Close()
}

Send-WakeOnLan -MacAddress 'AA-BB-CC-DD-EE-FF'

Schedule it ahead of your AlertMonitor patch windows, and let the sleep policy from step 2 put machines back down afterward.

5. Make the truck roll the last resort

Before dispatching anyone to a client site, open a remote session from AlertMonitor. Kiosk PCs, POS terminals, and thin clients that "need someone on-site" are usually one power-cycle or service restart away from healthy — a remote session resolves it in minutes, and the session log lands on the device timeline as proof.

6. Take a real number to finance

Baseline consumption, apply sleep policies and shutdown schedules, then pull the before/after from the AlertMonitor timeline: which device groups changed, when, with what results. "We cut roughly 40,000 kWh a year from the workstation fleet" is a sentence that changes how IT is perceived in budget meetings.

The Bottom Line

Moody's projection — 17% of Dutch electricity, 30% of Ireland's by 2035 — means one thing is certain: energy pressure isn't going away, and neither is the scrutiny on IT's share of it. The teams that come out ahead will treat power the way they treat patching: monitored continuously, remediated automatically, and logged end to end.

That's exactly what a unified platform buys you. One console where the UPS alert, the remote session, the remediation script, and the ticket all live on the same timeline — so the next power event is a 20-minute footnote instead of an eight-hour outage story.

Related Resources

AlertMonitor RMM & Remote Management AlertMonitor Platform Overview Book a Demo RMM & Remote Management Resources