Where a second path pays for itself on a mining site and where it just adds cost. A plain look at connectivity for a load that tolerates gaps.
A fleet owner planning a new site often starts the connectivity conversation the same way they would for a trading desk or a hospital: asking for two of everything. That instinct is not wrong so much as misdirected. An ASIC fleet is one of the more forgiving loads on a network, and the money spent chasing redundancy it does not need is money not spent on the one link that matters. The first question is not how much redundancy to buy, but where a gap in the network costs you something.
What a miner needs from the network
A mining machine's traffic is small and repetitive: it opens a connection to a pool, submits shares as it finds them, and receives new work in return. None of that requires much throughput, and none of it is particularly sensitive to a brief delay. A share that arrives after the pool has moved on to new work is rejected as stale, which costs a sliver of output rather than breaking anything, and a machine that briefly loses its connection keeps hashing against the last work it received rather than stopping outright. This is a different profile from a workload where a short gap causes a transaction to fail or a session to drop, and that difference belongs in the design before anyone prices a network built for the latter.
What the site does need is a link that comes back reliably after a fault, and monitoring that tells someone the link went down in the first place. Those two things matter far more to a mining fleet than raw capacity does, and they are also the two things a badly specified network tends to get wrong.
What breaks when the link drops
It helps to separate two things that a network outage affects differently. The first is production: while the uplink is down, machines cannot submit shares or receive new work, so output for that window is lost, in roughly the same way an interruption or a curtailment event costs output. Once the link returns, hashing resumes on its own, and a fleet with a properly configured backup pool address can often keep submitting shares through a different route without anyone intervening.
The second is visibility, and this is the part that tends to get missed. A network outage does not just stop shares from being submitted, it also stops the operator and the customer from seeing what the fleet is doing. Firmware cannot be pushed, a fault cannot be raised, and a machine that develops a genuine hardware problem during the outage may sit unnoticed until the link is restored. The production loss from a short outage is usually recoverable. The period of not knowing what happened on site is the part to protect against.
Where a second path earns its keep
Redundancy is not free at any layer, and it belongs where the failure it protects against is both likely and expensive. The uplink into the site itself is the layer where that trade usually makes sense, because a single circuit from a single carrier is a single point of failure for every machine on site at once, not just one customer's fleet. Ask whether the site's connectivity comes from one physical path or genuinely diverse routes, and whether a second carrier exists or whether the second circuit just runs through the same duct as the first.
Below that layer, the case for redundancy gets weaker quickly. Doubling switch hardware inside the site, or provisioning a second link per rack, protects against a failure mode that is both less likely and less consequential than the uplink going down, given how tolerant the load itself is of a brief gap. A cheaper and often more effective step is making sure each miner is configured with more than one pool address, so a routing problem on one path does not have to be resolved before the machine can submit shares again through another. That is a configuration choice rather than a hardware purchase, and it should be confirmed as part of fleet setup regardless of what redundancy exists at the site level.
Keeping the control network separate from everything else
Whatever the physical redundancy looks like, the traffic that manages the site should not share a network with the traffic that just moves shares back and forth. A site's control layer (the interfaces that manage individual machines, environmental systems and access control) is a different thing from customer-facing connectivity, and mixing the two on one flat network means a problem or a compromise on one side can reach the other. Ask how the host separates control traffic from tenant traffic: whether it is a logically separate network, a physically separate one, or whether everything sits on the same switch fabric with access rules doing the work instead.
This matters more than it might sound, because the control layer is also where remote access comes in. Firmware updates, pool changes and diagnostic access all pass through it, and how that access is authenticated and logged is a security question as much as a networking one. Our operations page covers how physical access to a facility is controlled and logged. Remote access deserves the same scrutiny: ask who can reach the control network remotely, whether that access requires more than a password, and whether a session is logged in a way you could ask to review.
What to ask before you sign
Bring a short list of questions to the connectivity conversation rather than accepting a single figure for the site's bandwidth:
- Ask whether the site's uplink runs over one physical path or genuinely diverse routes, and who the carriers are.
- Ask what happens automatically when the primary link fails: does traffic fail over, or does someone have to intervene first?
- Ask how you would find out the link was down if you were not watching the dashboard at the time.
- Ask how the control network is separated from customer traffic, and who can reach it remotely.
- Ask whether your fleet is set up with more than one pool address, rather than assuming it is.
A useful answer to any of these needs no number attached. What matters is whether the person answering can describe the mechanism rather than reciting a spec sheet from memory.
Fleet visibility during and after a network event is largely a monitoring question rather than a bandwidth one: what you want is status and pool configuration per device, including backup pools, in one place rather than scattered across whatever each machine reports on its own. Our operations page sets out the connectivity standard every facility is built to (fibre with a second path), so you can check the questions above against it before you commit.
