Reading an SLA: what 99.9% hides, penalties and exclusions

July 15, 2026 · 4 min read · SOVALYX Technologies

An SLA promising 99.9% availability allows nearly nine hours of downtime per year without the provider being in breach. Reading an IT SLA properly means converting percentages into real hours, hunting down the exclusions, and checking what the penalties are actually worth.

Converting the "nines" into real hours of downtime

A year contains 8,760 hours. The maths is simple: 100% minus the promised availability gives you the downtime the contract tolerates without penalty. That is where the illusions fall away.

"Three nines" sounds comfortable, yet the percentage says nothing about when outages happen or what shape they take: 99.9% can mean a single eight-hour outage in the middle of your billing run, or a series of tiny blips at night. The impact is not remotely the same. To connect those hours to their financial consequences, see our guide to the real cost of an hour of downtime.

The measurement period changes everything

The same percentage is worth different things depending on whether it is measured monthly or annually. Measured monthly, 99.9% allows only about 44 minutes of downtime per month — stricter than an annual measurement, under which a provider could concentrate almost nine hours of incidents into one bad week and still comply. The flip side: service credits are usually computed on that month's invoice, so a catastrophic month only triggers one month's compensation.

Then check how unavailability is established. Through the provider's monitoring? Your own probes? Or only from the moment you open a ticket — which quietly excludes any incident you failed to report in the required form? Read the contractual definition of "unavailable" too: a degraded service, slow to the point of being unusable, rarely counts as an outage in the text. And mind the scope: an SLA on the virtual machine says nothing about the application running on it.

Exclusions: where the SLA empties out

The exclusion list is the most important part of the document, because every line removes hours from the commitment. The most common:

• Planned maintenance: legitimate when properly framed — minimum notice, defined windows, a cap on hours. Without a cap, a provider can multiply "planned" interventions that never count as downtime.
• Broadly drafted force majeure: beyond natural disasters, some wordings slip in power failures or telecom carrier outages.
• Third-party failure: the clause with the heaviest consequences. If your provider resells a cloud platform it does not operate, an outage of that platform may be excluded — leaving the SLA covering almost nothing that would actually take you down. The four questions to ask after a cloud outage help you test this point.
• Customer acts: configurations, refused upgrades, capacity overruns. Understandable, but the boundary must be written precisely.
• Attacks: denial-of-service events are sometimes excluded wholesale, even though resilience to them is one of the reasons to outsource in the first place.

Penalties: symbolic credits or real compensation

Almost every SLA provides service credits: a percentage of the monthly fee, rising with the severity of the breach, and usually capped at a fraction of that month's invoice. Four points determine their real value: how they trigger (automatically, or on a customer claim within a short window — miss it and the right lapses), the overall cap, any "exclusive remedy" clause making credits the only compensation available, and the fact that they never cover your actual loss — a credit of a few percent will not refund lost revenue.

A serious SLA is recognisable less by the number of nines than by how verifiable the whole arrangement is: published metrics, systematic incident reports, penalties that apply without a legal battle, and an exit door after repeated breaches. That is the standard SOVALYX holds its own 24/7 monitoring commitments to. And remember that an SLA never replaces your internal recovery objectives: RTO and RPO remain your responsibility.

Checklist: ten points to verify before signing

1. Convert the promised availability into hours of downtime per year and per month.
2. Identify the measurement period (monthly or annual) and how downtime is established.
3. Read the contractual definition of "unavailable": does degraded service count?
4. Delimit the scope covered: infrastructure, application, network, dependencies.
5. Frame maintenance: notice, windows, cap, and how it counts in the calculation.
6. Scrutinise every exclusion, especially third parties and subcontractors.
7. Check how penalties trigger: automatically or on claim, and within what deadline.
8. Measure the credit cap and spot any exclusive remedy clause.
9. Require availability reports and incident post-mortems.
10. Provide for penalty-free termination after repeated breaches — and have the contract reviewed before signing.

🧰 The companion tool: Are you ready for the AI Act? — free · 2 minutes.

Reviewed and optimised by AI.