Home › Guides › GTR, SLA et MTTR

SLA, restoration time and MTTR: what your commitment is actually worth

Three acronyms appear in every hosting and connectivity contract, and almost nobody knows what they produce on the day of an outage. An availability figure is not a promise of continuity: it is a budget of minutes. A restoration time is not a repair promise: it is the point at which a penalty starts. And an MTTR commits nobody. This guide takes the three apart, then shows how to turn a real incident into a claimable amount.

Estimate my cost →

Four acronyms, four different things #

Response time: how long before somebody starts working on your outage. It says nothing about the end.
Restoration time: how long before the service must be back. It is the only one of the four that commits to an outcome.
MTTR, mean time to repair: an observed AVERAGE, usually across the provider's whole estate. An average is not a commitment, and your outage may be the tail of the distribution.
Availability, the nines: the share of time the service must be delivered over a period. It converts into minutes, and that is where it becomes concrete.

An availability figure is a budget of minutes #

A year holds 525,600 minutes. A 99.9 % commitment therefore allows 0.1 % of downtime, or 525.6 minutes: 8 hours and 45 minutes a year without any clause being broken. At 99.99 %, 52 minutes remain. At 99.999 %, 5 minutes 15 seconds. Each additional nine divides the budget by ten. Watch the reference period: the same 99.9 % applied MONTHLY allows only 43 minutes, a far tighter commitment. A contract that does not state its period is not saying much. See high availability and service-level agreement.

What each figure allows as annual downtime. One more nine divides the budget by ten.

Why MTTR does not protect you #

Mean time to repair is an operations metric, useful to a provider steering its teams. It becomes misleading the moment it is used commercially: a two-hour average is perfectly compatible with a nineteen-hour outage, if the others lasted twenty minutes. MTTR pairs with mean time between failures to produce a theoretical availability, which describes statistical behaviour, never a contractual right. What protects you is the restoration time and the penalty attached to it.

What the commitment covers, and what it does not #

Scope: does it cover power only, or cooling too? A cooling failure that takes the room to 60 °C is not a power cut, and many contracts do not cover it.
Measurement: who records the downtime, from which probe, and from what timestamp? Without a defined measurement point, the duration is arguable.
Maintenance exclusion: planned windows are almost always outside the calculation.
The cap: the penalty is bounded, often a share of the monthly fee. One free month never compensates a day of stopped production.
The claim window: seven to thirty days after the incident. Once it lapses, the right is gone, and that is the first cause of non-payment.

Contractual credit, insurance, business losses: three separate pockets #

The credit set out in the contract is a bounded commercial gesture, calculated on what you pay. It does not repair your loss. Damage suffered falls to your insurer or to the operator's liability, two different grounds with their own exclusions. Business losses are almost systematically excluded from hosting contracts. Confusing these three pockets leads to claiming the wrong thing from the wrong party, while the claim window runs.

Turning an incident into a claimable amount, step by step #

Pin the exact incident window, with timestamped sources: tickets, monitoring, logs.
Check the cause falls inside the covered scope, and is not an announced maintenance.
Subtract the downtime budget the figure allows over the reference period.
Apply the penalty formula to the excess, then the cap.
Compare with the monthly fee concerned, not with lost revenue.
Send the dated claim to the escalation channel, before the window lapses.

What DataColoc computes, and what it does not know #

The comparator turns a figure into a downtime budget, places your incident inside it, and applies the barème DECLARED by the site when one exists. Where no barème is published, the calculation stops and says so: an invented amount would be worse than no answer. Today very few listings declare theirs, and it is precisely the data an operator has an interest in publishing, because it reassures a buyer before it binds him.

What to remember #

An availability figure is a budget of minutes, not a promise. A restoration time commits to an outcome, a response time only to a start, an MTTR to nothing. The real value of a commitment sits in three clauses only: scope, penalty formula, and claim window. Ask for those three in writing before signing; after an incident, calculate before calling, and send it dated.

FAQ #

How many hours of outage does 99.9 % allow?

Over a year, 8 hours 45 minutes. Over a month, 43 minutes. The reference period changes everything: a monthly commitment is far tighter than an annual one at the same figure.

What is the difference between response time and restoration time?

Response time is how long before work starts, restoration time how long before the service is back. Only the second commits to an outcome. A contract showing only a response time does not guarantee the end of your outage.

Does my provider's stated MTTR commit them?

No. It is an average observed across their estate, not an obligation towards you. A two-hour average remains compatible with a nineteen-hour outage at your site.

Can I claim business losses from the operator?

Almost never through the hosting contract: they are explicitly excluded in nearly all cases. The contractual credit is computed on what you pay, not on what you lose. The loss itself is an insurance matter.

I found out about the incident three months later. Can I still claim?

Usually not. The claim window is seven to thirty days depending on the contract, and its expiry ends the right. It is the first cause of non-payment, ahead of scope.

Written on 6 September 2026.