Curtailment — deliberately powering the fleet down through expensive hours and back up for cheap ones — is one of the highest-leverage moves in mining economics. On many time-of-use tariffs, a few peak hours carry a large share of the day's energy cost while contributing the same revenue as any other hour. Skipping them is often straightforwardly profitable. What is not straightforward is doing it hundreds of times a month across hundreds of machines without stranding hardware, waking clients' miners nobody agreed to sleep, or training your own team to ignore alerts. This guide is the version of that lesson we wish we'd been handed.
There are three broad ways to stop a miner drawing power: cut the circuit (breaker/PDU), let firmware throttle it, or use the firmware's own sleep mode. Cutting power works but is hardware-dependent and brutal to schedule remotely. Throttling sounds attractive but on the stock firmware of many widely deployed generations it simply isn't exposed. That leaves firmware work-mode sleep — the manufacturer's own low-power state — which is what we use: the machine stops hashing, drops to a trickle of draw, and stays reachable on the network for the wake-up call.
The reboot-persistence trap. Here is the one that bites: on older stock firmware (we verified this live on 2022-era Antminer S19j units), sleep mode persists across reboot. A power blip in the middle of your curtailment window — or a well-meaning technician power-cycling a "dead" machine — boots the miner straight back into sleep. It will sit there indefinitely, drawing idle power and earning nothing, looking exactly like a hardware failure. Any curtailment system must therefore own the wake-up: sleep is only safe when something reliable is guaranteed to send the wake command and confirm it landed.
Miner firmware acknowledges configuration writes optimistically; the web interface can even stall mid-apply while the change goes through anyway. The only trustworthy pattern is write, then read back: command the sleep, then poll the machine's actual work mode until it reports the state you asked for (or a timeout tells you it didn't). The same on wake. A fleet where 96 of 100 machines woke and four silently didn't is a fleet losing four machines of revenue until someone happens to notice — read-back turns that into a named list with reasons, minutes after the window closes.
A hosting operator curtails other people's machines. That's a contractual matter before it's a technical one — some clients happily trade peak-hour downtime for lower power costs, others are paying precisely for maximum uptime. Curtailment participation should be a per-client setting, off by default, visible to the client, and reflected in their reports. In our platform that's exactly how it ships; whatever tooling you use, resist the temptation of a single site-wide switch that quietly decides for everyone.
The quiet killer of curtailment programs is what they do to monitoring culture. If scheduled sleep raises the same "site offline" alarms as a real failure, your team learns within a week that offline alerts are usually noise — and then the real outage arrives to an audience of muted phones. Planned downtime must be first-class state: the site shows as intentionally curtailed, offline alerting suppresses for exactly that scope and duration, and everything outside the plan still fires at full volume. Uptime arithmetic should treat planned windows as planned, or your own SLAs will argue with your own schedules.
Curtailment inside Helios Forge Fleet is built to this checklist because we ran into every item the hard way: schedules per site and time zone, sleep and wake through each miner's own firmware with read-back verification, per-client opt-in, and curtailed sites marked honestly so alerts keep their credibility. The details live on the power management page — or request a demo and bring your tariff.
