Foreman Mining Management Guide: Fleet Monitoring

Foreman is a cloud-based monitoring and control platform aimed at mid-size and large ASIC operations. Where a local tool runs on a host inside the farm, Foreman mining management polls miners through a small on-site agent and presents the fleet in a browser from anywhere. It leans into curtailment and demand-response — features that matter where electricity contracts pay miners to power down during grid peaks. This guide covers how Foreman connects to miners, what it monitors, how its automation and curtailment work, and where it fits relative to firmware-native tooling. It assumes the reader already runs miners with reachable APIs.

What Foreman does for a mining operation

Foreman discovers ASICs on the local network through an agent, reads their APIs, and reports hashrate, temperature, fan status, pool connection, and error counts to a hosted dashboard. From that dashboard an operator can reboot, reconfigure pools, change power modes on supported firmware, and group miners for bulk action. The platform is subscription-priced per managed device and supports Antminer, Avalon, Whatsminer, and Goldshell families among others.

Its standout area is energy management. Foreman can curtail — throttle or pause — miners on a schedule or in response to a signal, which is how farms participate in demand-response programs without manually pulling breakers. For sites on time-of-use rates, that automation directly shapes the power bill. Foreman is one console in a broader category; the ASIC remote monitoring stack guide sets it alongside the alternatives.

Connecting miners through the Foreman agent

Because Foreman is cloud-hosted, it does not reach miners directly over the internet. Instead, a lightweight agent runs inside the farm — on a Raspberry Pi, a mini-PC, or a small server — and relays data between the local miners and the Foreman cloud. Install the agent on a host that stays powered and sits on the same network as the miners.

After the agent registers with the account, run discovery. The agent scans the configured IP ranges and lists found miners with model and firmware detected. Confirm the host can reach every miner subnet; segmented networks need routing in place first, following the same logic as the mining network setup guide. Assign each miner a stable address through DHCP reservation or static configuration so the agent’s references survive a reboot.

Naming and grouping conventions

Adopt a naming scheme before the fleet grows. Encoding site, rack, and position into the miner name — for example A-R3-12 — turns a wall of identical model names into a map an operator can troubleshoot from. Group by circuit or PDU as well as by model, because curtailment and load questions are answered at the circuit level.

The circuit-level grouping is what makes Foreman’s energy features usable. A curtailment command issued to “Circuit 4” only makes sense if the platform knows which miners sit on that circuit, and that knowledge comes from the grouping an operator builds at onboarding. Skipping it forces every curtailment action to be assembled by hand, which defeats the automation. Spend the time mapping miners to circuits once and the energy tooling pays it back every billing cycle.

Tag by model as well, since power-mode behavior and rated output differ by machine. A curtailment that throttles an S21 XP and a Goldshell altcoin box by the same absolute wattage affects them very differently; tagging by model lets a rule scale its action to each machine’s nameplate rather than applying a blunt uniform cut across a mixed fleet.

Monitoring, thresholds, and alerting

Foreman’s dashboard summarizes total fleet hashrate, online-versus-offline counts, and aggregated power where firmware reports it. Drill into a single miner for per-board hashrate and temperature. Set alert thresholds relative to each model’s rated output rather than a flat hashrate, since a mixed catalog of Bitmain SHA-256 units and Goldshell altcoin boxes spans a wide range.

Route alerts to email, SMS, or a messaging webhook. Temperature alerts should fire below the firmware’s thermal-throttle ceiling so the warning precedes the derate. Track recurring soft faults — units that drop and self-recover — because that pattern usually signals a marginal power supply or a failing fan, both of which feed a maintenance queue rather than a software fix.

Automation and curtailment

Foreman’s automation rules trigger actions from conditions: reboot a miner that stalls, switch power mode when a temperature is breached, or pause a group on a schedule. The curtailment engine is the differentiator. Operators can define curtailment windows tied to time-of-use pricing, or expose a control endpoint that a utility demand-response program can call to shed load during grid stress.

Curtailment that pauses a miner cleanly is gentler on hardware than yanking power. Where the firmware supports it, a power-down command lets fans spin down and avoids the thermal-cycling stress of hard cuts. Operators sizing their electrical service around curtailment should still plan for full draw at the breaker; the three-phase power sizing guide covers that headroom math.

Demand-response economics

In regions with demand-response programs, the payment for curtailing during peaks can rival mining revenue for those hours. Foreman’s automation makes participation hands-off, but the economics are region- and contract-specific. Frame any projected savings as dependent on the local utility program and the hashprice at the time — these shift, and a curtailment that pays in winter may cost mined revenue in a high-hashprice month.

The decision logic is a comparison at each curtailment window: the value of mining for that hour versus the value of the demand-response payment plus the avoided power cost. When hashprice is high, mining may win even during a peak; when it is low, curtailing is the clear call. A static schedule cannot make that comparison, which is why operators serious about the economics tie curtailment to a price signal rather than a fixed clock. The point is that the platform automates execution, not judgment — the thresholds still reflect an operator’s read of where mining economics sit, and those are checked against live data, not set once and forgotten.

Foreman versus firmware-native and local tools

Foreman’s cloud model suits operators who manage multiple sites, want browser access from anywhere, and value curtailment automation. The per-device subscription is the trade-off against locally hosted tools that charge once. For operators who prefer software on their own hardware, the Awesome Miner setup guide covers a local alternative, and the Minerstat setup guide covers another cloud option with a different feature emphasis.

Foreman monitors and controls; it does not replace the tuning that custom firmware provides on the miner itself. Power-mode changes it pushes are only as granular as the underlying firmware allows. Operators chasing efficiency gains usually pair a monitoring platform with firmware-level autotuning, a topic the ASIC autotuning guide develops in detail.

Security and the cloud-access trade-off

Foreman’s cloud model is convenient and carries its own considerations. Control of the fleet flows through a cloud account, so account security is fleet security — a compromised login can reconfigure or stop machines. Use a strong, unique credential and enable any available second factor. The on-site agent is the bridge between the cloud and the miners, and it should run on a host that is itself secured and segmented from general network traffic, following the same isolation logic as the static IP and firewall configuration guide.

Consider what happens if cloud connectivity is lost. The miners keep hashing on their last configuration even when the agent or the cloud is unreachable, so a brief internet outage does not idle the fleet — but it does blind the operator until connectivity returns. For sites where the internet link is unreliable, that visibility gap is the main argument for keeping a secondary local view as a fallback, a point the monitoring-stack overview develops.

Setting up Foreman the right way the first time

Start small. Onboard one rack, confirm discovery and alerting work end to end, then expand. Verify that the agent host is on a UPS or has a reliable power source, because if the agent dies the cloud loses visibility even though the miners keep running. Document the IP plan and naming scheme in a place separate from Foreman so a fresh agent can be rebuilt quickly.

Test an alert deliberately — pull a network cable on one test unit — and confirm the notification arrives where expected. An untested alert path is the most common reason an outage goes unnoticed despite monitoring being “set up”. Once the workflow is proven, the platform scales to hundreds of units. The hardware feeding that fleet still has to clear its power cost; the Coin Web Mining shop lists current models with published efficiency numbers to compare against.

Plan for the agent’s own resilience as the fleet grows. A single agent is a single point of failure for visibility, so larger operations sometimes run more than one agent or keep a spare host ready to deploy the agent quickly if the primary dies. The miners keep hashing through an agent failure, but the operator is blind until it returns, and a blind operator misses the faults that monitoring exists to catch. Treat the agent host as production infrastructure with the same care given to the network gear, and document its rebuild steps so a replacement comes online in minutes rather than hours.

References

• ASIC efficiency and rated-hashrate specifications — ASIC Miner Value
• Hashprice trends for curtailment economics — Hashrate Index
• US electricity pricing and demand-response context — US Energy Information Administration
• Firmware power-mode and API reference — Braiins