Every mining operator eventually gets the call: the site is dark on the dashboard, nobody knows why, and the first instinct is to imagine racks of dead machines. Having lived through our share of uplink failures — including one that took two co-located sites offline at once — here is what actually happens, what it costs, and what it should change about how you build.
An ASIC miner earns by holding a TCP connection to its pool and working on the jobs the pool sends. When the site's WAN link dies, that connection dies with it — and without fresh work from the pool, the machine has nothing valid to hash. Stock firmware handles this ungracefully but harmlessly: the miner drops into an idle-and-retry loop, attempting its configured pools (primary, then backups) over and over until one answers. Fans keep spinning, boards stay powered on most firmware, and the machine sits there consuming a fraction of full load while earning exactly nothing.
Two reassurances worth internalizing. First, hardware is not at risk — an outage is thermally the gentlest thing that ever happens to a miner. Second, recovery is usually automatic — when the link returns, the retry loop reconnects and hashing resumes on its own, typically within a minute. The machines almost never need you. The outage's real costs live elsewhere.
Revenue loss is immediate and linear — a 100-miner site at roughly 100 TH/s per machine stops contributing about 10 PH/s the moment the link drops, and nothing on site can buy that time back. But the second cost is the one that compounds: you can't see the site anymore. Every remote judgment — is this an ISP problem, a dead router, a power event, a fire? — now rests on whoever you can reach by phone. The difference between a 20-minute blip and a wasted three-hour truck roll is usually just knowing which of those it was.
This is also where monitoring platforms show their character. Local management traffic doesn't stop — the miners are alive on the LAN — so an on-site agent keeps collecting even while it can't report. When connectivity returns, a well-behaved system resumes cleanly: queued commands deliver, telemetry catches up, and the record shows an outage rather than a mystery. That behavior is worth explicitly testing with any tool you run: unplug the WAN for ten minutes and watch what the platform claims afterward.
The outage that taught us most took down two sites simultaneously — because they shared one uplink. Three lessons came home with the postmortem:
Helios Forge Fleet was shaped by exactly these events: commands queue through outages, the site's history says "offline" honestly instead of guessing, curtailment is marked as planned so it never cries wolf, and alert routing has fallbacks because someone once configured none. If that sounds like the operational temperament you want watching your sites, request a demo.
