How to read a service level agreement, which remedies are worth having, and how to spot a number that cannot be enforced when it matters.
At a glance, the service-level clauses in mining hosting contracts look interchangeable: a percentage, a remedy, a page or two of exclusions. Read line by line, two of them rarely promise the same thing. The gap between what a clause says and what it can deliver is where most disappointment in this business comes from, and it is findable before you sign, not after.
What a service level can measure
A service level is only as good as the thing it is measuring. Power availability, measured at a defined point, is measurable and enforceable, because either the meter shows power flowing to your row or it does not. Hashrate is a different case: it depends on firmware, pool configuration and machine condition as much as on anything the host controls, so a clause promising a hashrate figure is promising something the host does not fully control, which should make you ask how it can be measured and against what baseline. Response time to a fault is measurable if the clock starts and stops on defined events (ticket logged, technician on site or issue resolved), and unenforceable if it is left as a general commitment to act promptly. Before comparing two contracts on their headline number, check that both numbers describe something that can be read off a meter or a log, not something inferred after the fact. Our piece on uptime and availability goes into what the availability figure itself needs to state before it means anything.
Exclusions decide the real scope of the promise
Every service level comes with a list of things that do not count against it, and that list, more than the headline percentage, sets the scope of the promise. The usual entries (planned maintenance and force majeure) are covered in the availability piece linked above, along with the questions to ask about each. What deserves closer reading here is anything that works as an exclusion for the host's own operational choices: a vague reference to "network conditions" or "third-party equipment" that could cover a fault sitting squarely inside the host's own infrastructure. A short, specific exclusion list is a better sign than a long, vague one, because a host that can name exactly what it will not be held to has thought about where the line sits.
What a credit is worth once it is capped
A service credit is the most common remedy, and a useful one, but only once you know what it is calculated against and what caps it. A credit calculated against the fees for the affected machines during the affected period behaves differently from one calculated against total monthly fees, and a credit that is capped at a small share of the invoice behaves differently again once an outage runs long enough to reach that cap. Ask, specifically, what the credit is a percentage of, whether it scales with the length or severity of the miss, and what happens once the cap is reached: do further hours of downtime simply stop being compensated? A credit clause that answers all of this in the document itself is a stronger clause than one that states a headline figure and leaves the mechanics to be worked out later.
Who measures, and what happens when the number is missed
A service level is only as trustworthy as the measurement behind it, and the agreement should say plainly who takes the reading, where the equipment sits, and whether the fleet owner has any independent way to check it. A host that reports a monthly summary compiled from its own systems, with no way for you to see the underlying reading, is asking you to trust a number you cannot audit. A host that gives you a live reading at the same point the contractual figure is calculated from is giving you something you can check against your own records as the month goes, not just after the invoice arrives. Ask specifically whether the metering point for the service level is the same one used for billing, and whether you can see it directly.
That question sits alongside a second one: what happens when the number is missed and nobody notices in time. A service level agreement can specify a number, a measurement point and a remedy. It cannot, on its own, guarantee that a fault gets fixed quickly, because fixing a fault depends on people, parts and access, not on the wording of a clause. What the agreement can specify is the escalation path that runs alongside the number: who is notified first, what happens if that contact does not respond within a stated window, and who has authority to approve work that goes beyond routine maintenance, such as the remote hands work covered in our piece on remote hands scope and cost. A clear escalation path does not replace a strong number, but a strong number without one leaves you waiting on one contact with no defined next step if that contact is unavailable.
What to check before you sign
Comparing two agreements on the headline percentage alone tells you very little. Before you sign, confirm each of the following is stated in the document itself, not left as something you were told on a call: what is measured and at what point, the full exclusion list, how a credit is calculated and what caps it, who measures and whether you can verify it, and what the escalation path looks like when the first contact does not respond. A host willing to put all five in writing has already told you something about how the relationship will run when something goes wrong.
The highest number on the page is the least useful thing to compare. What counts is how you would prove a miss and what it would owe you, and the availability piece linked above covers the measurement behind the headline figure in more depth. Our operations page lists what we commit to, from remote hands response to incident notification, and how each commitment is evidenced.
