Mining Hosting SLA and Maintenance

An SLA, or service level agreement, is a contractual text. Many hosted-mining offers display one, and few are equivalent. What follows is a reading guide that applies to any offer.

What an SLA covers

Three blocks recur without exception.

Uptime. A percentage of time the service is deemed delivered. That service is often defined as "power and network to the machine", sometimes as "observed hashrate". The definition matters more than the percentage, because hall uptime is not your ASIC's uptime: a powered bay with a dead miner counts as available if the SLA only speaks about infrastructure.

Replacement. The conditions under which a machine, a power supply, or a hashboard is swapped. To clarify: OEM part or equivalent, spare available on site, or a wait on manufacturer RMA. A replacement that points you back at the vendor is not a hosting service, it is a redirection.

Response time. The delay between opening a ticket and a first action, acknowledgement, diagnosis, or dispatch. That is not resolution time, and a serious SLA separates the two while grading severity: a dark hall and a noisy fan do not call for the same urgency.

Usually outside scope, absent express mention: failures of the miner itself, unstable firmware, an unreachable pool, your own internet provider, planned maintenance, and whatever the contract files under force majeure.

Decoding a "99.x %"

A one-decimal percentage says nothing until five points are established.

The basis. 99.x % over a month, a quarter, or a year? An annual average absorbs an entirely black month without pushing the figure out of range.

The scope. Power, network, cooling, or all three? Is the measurement taken at the main board or at your machine's receptacle?

The carve-outs. The longer the exclusion list, the less the percentage binds. Planned maintenance and "customer acts" are often enough to empty the clause of substance.

The associated credit. The usual remedy is a credit on the hosting invoice, generally capped at a fraction of the period. It is almost never an indemnity matching unmined bitcoin. Without a stated formula, the percentage commits to nothing.

The evidence. Who measures, with which logs, and can you export them? Uptime that exists only on an internal dashboard is hard to enforce.

Translated into hours across a thirty-day month, the difference between two commitments becomes concrete:

Commitment	Downtime tolerated per month
99.0 %	7 h 12
99.5 %	3 h 36
99.9 %	43 min
99.99 %	4 min

Each additional nine divides allowed downtime by ten, provided the definition is honest. Note in passing that on a machine clearing about $6.80 of margin per day, seven hours of downtime represents under $2: an SLA's value does not sit in the credit it pays, but in the operating discipline it imposes on the site.

Firmware

Three questions to ask: who may flash, with which file, and after what sign-off.

The risks are concrete. An overclock image pushed by the operator to hold its density wears your hardware at your expense. A security patch can be refused because the image is not in the internal catalogue. And a pool configuration is regularly lost during a flash, which sends your hashrate elsewhere without anyone noticing immediately.

Require three guarantees: preservation of your pool URLs, a documented rollback path, and no change to firmware fees without your written consent. Without machine access, a firmware SLA reduces to a ticket queue.

Repairs, RMA, heat, and dust

Preventive work, blow-out, connector checks, fan listening, and temperature logging, is not always included. Ask for a written interval and the rate charged for each additional visit.

On-site intervention mobilizes spares, a technician, and local downtime. RMA means pack-out, freight, a vendor queue, and a machine gone for several weeks. The contract must answer three questions: who pays the freight, is a loaner fronted, and is the slot still billed during the absence? On a five-week RMA, that last line weighs more than the price of the part.

Heat and dust are the two wears the building inflicts on your hardware. A poorly filtered or overly dense hall accelerates power supply and fan mortality. The contract should state target temperature bands, a cleaning regime, and whether a measured miss opens a credit or falls under best efforts only.

Always document the intake condition of your machines: photos, serial numbers, hashrate test. Without that baseline, any discussion about an RMA or about cleanliness reduces to competing accounts.

Read the SLA after the limitation of liability

Reading order is what counts. If damages are capped at a month of fees and lost profits explicitly excluded, the uptime percentage only computes a small credit, whatever its headline value.

An SLA also does not replace clear title to the machine, pool credentials in your name, or a workable exit clause. And it never turns a host into an insurer of the bitcoin price.

The six checks

1. The service definition: infrastructure or observed hashrate.
2. The exclusions and the treatment of planned maintenance.
3. The split between response time and resolution time, by severity level.
4. The replacement and RMA rules: who pays, who waits, who keeps billing.
5. The credit: formula, cap, and enforceable proof.
6. Firmware, cleaning regime, and thermal bands.

A clause that does not survive those six checks belongs to the sales pitch. What you sign is a text, not an adjective.