Monitoring a mining farm: useful metrics and alerts
Track each physical miner and make alerts actionable instead of collecting an unreadable stream of numbers.
ASIC.tools · Reviewed
Give each device a stable identity
Assign a distinct worker name and connect it to the device serial number, model and rack location in an inventory. A pool can only distinguish miners to the extent that their submissions identify separate workers. Keep the physical asset identifier stable when addresses or pool accounts change. Without that mapping, an offline alert may tell you revenue is missing but not which machine needs attention.
Combine local and external observations
Collect local hashrate, board status, temperature, fan state and uptime where supported. Pair them with pool accepted-work estimates and a separate view of site power and internet availability. Local hashing does not prove that useful work reaches the pool. Conversely, a short pool estimate can fluctuate without hardware damage. Preserve timestamps and measurement intervals so the two views can be reconciled.
Choose thresholds from a baseline
Measure normal behavior at the approved profile before setting alerts. Allow for startup, tuning and scheduled maintenance rather than treating every temporary dip as a breakdown. Use documented hardware safety limits independently of statistical performance thresholds. An unusually low worker estimate and a thermal protection event deserve different urgency and different responses. Review limits after a deliberate change in power target or hardware configuration.
Attach a response to each alert
Every alert should identify the asset, symptom, first occurrence and next safe check. Decide who receives it and how escalation works if nobody responds. Group correlated failures so a lost upstream connection does not generate hundreds of independent repair tasks. Preserve the individual affected-device list. Test the delivery channel with a planned event and make sure recovery notifications close the same incident.
Use history to improve operations
Review repeated failures by device, rack and shared infrastructure. Track time to detection and time to recovery separately. Keep maintenance events alongside measurements so an intentional shutdown is not mistaken for an unexplained outage. Grant monitoring tools only the permissions they need and protect exported data. The goal is a shorter, more accurate response to lost productive time, not a dashboard with the largest number of charts.
