Winning the Volatility Game: Automated Load Control on the Grid

High-price windows do not wait for a group chat

On a market like ERCOT, electricity is not a stable input cost. Day-ahead prices move hourly. Real-time prices settle in 15-minute windows. They can sit in a quiet range most of the time. When the grid is tight, they can also jump sharply in a short window. For a large mining site, that is not a month-end accounting issue. If load stays up through the high-price hours, the power bill can erase a long stretch of mining profit. If load does not return when prices fall, the site stopped when it should have—and then missed the hours it should have been hashing.

The time that actually gets lost is rarely “we did not see the price.” It is the time spent confirming which machines to switch, who is allowed to switch them, and whether last week’s range list still matches the floor. Slow human confirmation misses the window. Putting the whole site into sleep at once drops a large share of load in a short time, and the site’s power equipment has to absorb that change. Many sites can already monitor whether miners are online. The missing next step is what should change, in what order, and how to prove it afterward.

Price, time, and DR are not the same switch

ItsMiner is a Bitcoin mining management and real-time rig monitoring platform. Load Control runs as tasks. Price, time, and demand-response (DR) signals are configured separately because they are not the same job on site.

Price tasks ingest ERCOT day-ahead prices and real-time series (typically 15 minutes; some markets 5 minutes). Operators set a threshold and how many consecutive price points must meet it. Auto-execute is a switch on the task. A newly created task does not turn it on for you. Some sites still want a person to confirm after the price condition is met. Others enable auto-execute only inside a defined afternoon window. If price data is missing, the system should not treat the blank as $0 and run.

Time-based tasks cover hours already on the calendar that do not depend on the live price. A power-purchase contract may require the site to reduce load during set weekday hours. Some bills are based on the month’s highest power draw, so the site needs to stay off a fixed daily peak. Those tasks can repeat on selected weekdays or run once. When the site already knows when to reduce and when to restore, it does not need to wait for another shortage price.

DR is an external signal, not a price formula. The system can connect to sources such as CPower, CSD, Gasum, and Voltus, and it distinguishes test, active, update, and cancel states. Test signals go into trigger records and are not executed. An active signal can auto-adjust load and restore after the window, with optional early execution. If more than one task is in play, the instance already running wins. In priority, DR outranks price, and price outranks a time-based task.

The miner-side action is a work-mode change: Normal, Sleep, Low Power, or a custom mode the firmware supports. What the site can check is whether the mode changed and which units were skipped.

Batch, skip, and hold sleep

If the whole site sleeps or restores at once, load can fall or rise by several megawatts in a short time. Batching splits that change. Tasks set batch size and interval: 100 to 3,000 miners per batch, 10 to 1,800 seconds between batches, or grouping by /24 subnet. A 5 MW site and a 100 MW site need different cadences. ItsMiner does not pre-set one batch profile for every farm. Each site configures this from its own size and how fast load is allowed to change.

Scope can be a sub-account, model, IP segment, or a picked list. If a hosting site needs one client’s machines to move first, that is set in the task range and execution order. The system does not decide on its own which group goes first. Miners already in the target work mode are skipped instead of receiving a redundant command.

After a high-price window, what operators often fear is not the first sleep command. It is the miner that wakes itself. After a flicker or reboot, firmware tries to come back online. If a load-reduction task is still waiting to restore, that “self-heal” is unauthorized power use. Anti-wake is bound to the current task. It starts after adjustment commands have finished and the task is waiting to restore. It covers in-scope, racked miners whose monitor is online, and each attempt is written to Operation Records. It only applies while that task is waiting to restore. It does not lock the whole farm.

Restore is configured separately: target mode, the same style of batching, and a policy after network or power loss—auto restore, keep the current mode, or wait for confirmation. Reduce without a defined restore, and the hashrate gap is still unexplained the next day.

If it cannot be reviewed, it is not done

After a shortage window, management rarely asks whether someone “handled it.” They ask which signal started it, how many machines moved, how many were skipped, when restore began, and whether hashrate came back.

Load Control keeps that chain: trigger records (including DR event IDs and test versus active state), execution records (planned versus actual counts, skips, success and failure, duration), a 48-hour Gantt aligned with the price curve, energy and price exports, Dashboard notifications, and Operation Records. For an example only, not a customer case: a site sets a real-time price rule, enables auto-execute for afternoon hours, batches Sleep by subnet, holds anti-wake until prices fall, then restores Normal. The useful output is a timeline that can sit next to the settlement statement.

Load Control is a Deluxe capability. It will not choose the threshold for the site. It turns a judgment into a miner action that can be reviewed. Price volatility is not going away. Only a site that can execute steadily, and explain the event afterward, can treat volatility as an operating condition.

Contact us for a demo:

• Email: sales@powsell.com
• Telegram: @ItsMinerOfficial