Understanding uptime reports: SLAs, MTTR and the "nines" of availability

An uptime report lands every month, tacked on to your hosting invoice, and usually says just "99.97%". That number alone won't tell you whether your provider has honoured the contract. To know that, you need to know how many minutes it represents, over which period it's calculated, and what the SLA stipulates if it's breached.

What does "99.9% uptime" mean in actual minutes

Each additional "nine" in the percentage is not just cosmetic: it cuts the permitted downtime by roughly tenfold. Here are the values on a monthly and annual basis, calculated on the calendar:

Guaranteed uptime	Downtime per month	Downtime per year
99% (two nines)	approximately 7 hours and 12 minutes	approximately 3 days and 15 hours
99.9% (three nines)	43 minutes and 50 seconds	8 hours 45 minutes and 58 seconds
99.95%	21 minutes and 55 seconds	4 hours 22 minutes and 59 seconds
99.99% (four nines)	4 minutes and 23 seconds	52 minutes and 36 seconds

99.9% is the most common standard in commercial hosting and cloud contracts, but it doesn't mean "practically always up": it allows for roughly 43 minutes of downtime each month. To reach 99.99%, you need redundant infrastructure, automatic failover and alerting systems that catch a fault in minutes, not hours.

The time window matters as much as the percentage

A report that calculates uptime on an annual basis can hide spikes that a monthly report would immediately show. Measuring 99.9% on an annual basis leaves room for a single blackout of nearly 9 hours, so long as the rest of the year stays clean; measuring it on a monthly basis, on the other hand, triggers the threshold every single month. When reading a report, always check which period the percentage is calculated over, not just the final number.

MTTR and MTBF: the two metrics that uptime percentage alone doesn't tell you

The uptime percentage shows the final result, but two sites with identical 99.9% could have had completely opposite histories: one had a single long outage, the other had ten brief interruptions. This is where two metrics come in, which a good monitoring report should list separately:

• MTTR (Mean Time To Repair): the average time between a fault being reported and the service being restored. A low MTTR means that when the server goes down, your provider gets it back up quickly.
• MTBF (Mean Time Between Failures): the average time between one fault and the next. A high MTBF means faults are rare, regardless of how long they last.

A hosting provider with MTTR of 5 minutes and MTBF of 2 months has a different profile from one with MTTR of 2 hours and MTBF of 1 year, even if the total monthly downtime might work out the same. For an e-commerce operator, the first profile (frequent but very brief outages) is often less damaging than the second (rare but lengthy), because a 2-hour blackout during a sales peak costs more than ten 10-minute blackouts scattered through the month.

How to read thresholds and credits in a real SLA

The SLA (Service Level Agreement) is the part of your contract that turns the uptime percentage into an economic right: if your provider doesn't meet it, you're entitled to a credit or discount. The typical mechanism has three elements: a guaranteed uptime threshold, a table of credits scaled by how far you fall below the threshold, and a deadline by which the customer must report the service failure to claim the credit.

A concrete and verifiable example is Amazon's official EC2 SLA, updated 25 May 2022. AWS distinguishes two levels:

SLA Type	Guaranteed threshold	Monthly uptime	Service credit
Region-Level (instances across 2+ Availability Zones)	99.99%	between 99.0% and 99.99%	10%
Region-Level	99.99%	between 95.0% and 99.0%	30%
Region-Level	99.99%	below 95.0%	100%
Instance-Level (single instance)	99.5%	between 99.0% and 99.5%	10%
Instance-Level	99.5%	between 95.0% and 99.0%	30%
Instance-Level	99.5%	below 95.0%	100%

AWS credits are calculated as a percentage of the monthly invoice for the affected service and are applied only to future payments, not as a direct refund. To receive them, the customer must open a support case before the end of the second billing cycle following the incident, and the credit is only issued if it exceeds 1 dollar.

Among Italian providers the logic is similar but the thresholds vary considerably. Some examples found in publicly available SLA schedules: one provider applies a 10% refund if monthly uptime falls below the guaranteed value down to 97.5%, and 20% if it falls below 97.5%. Another sets the threshold at 99.9% and grants a credit of 10% to 100% of the monthly fee, usable the following month, with a right to direct refund only if the outage exceeds 2 continuous hours.

Before signing or renewing a hosting contract, it's worth checking three things in the SLA, not just the percentage advertised on the homepage:

1. Over which time window uptime is calculated (monthly or annual: it makes a big difference, as we've seen above).
2. What is excluded from the calculation: scheduled maintenance, force majeure, customer-side issues are typically excluded even in the most generous contracts.
3. The claim deadline: most providers require notification within a short window, often 30 days from the event or within the first few days of the following month; beyond that deadline the credit is no longer due, even if the service failure actually happened.

How to read a report month by month

An honest monitoring report, in addition to the final percentage, lists individual incidents with date, start time, duration and cause. To verify whether the SLA was met, simply add up the minutes of downtime for the month and compare them against the threshold corresponding to the guaranteed percentage (see the first table): if the total exceeds that number of minutes, you're entitled to the credit stipulated in your contract, regardless of how "high" the final rounded percentage sounds in the report.