How to Read a Cloud SLA Before You Sign It

A cloud SLA is not a promise that the service will stay up. It is a formula describing how small a refund you get when it does not. That sounds cynical until you read a few of them side by side, which is what we do when evaluating providers. This guide covers the three things to work out before signing: what the uptime number means in real hours, what the credits are actually worth, and what the exclusions quietly remove.

What does 99.9% actually mean in hours?

Availability percentages compress badly into intuition, so convert them to downtime before comparing anything. The math is simple — take the allowed failure fraction and multiply by the period. We ran these in Python rather than trusting memory:

Uptime	Allowed downtime per year	Per month (730 h)
99%	87.7 hours	438 minutes (7.3 h)
99.5%	43.8 hours	219 minutes
99.9%	8.77 hours	43.8 minutes
99.95%	4.38 hours	21.9 minutes
99.99%	52.6 minutes	4.4 minutes

Two observations from years of reading these. First, the jump from 99.9% to 99.99% is the expensive one — it is the difference between “an incident each quarter is within contract” and “almost nothing is.” Second, check whether the SLA measures monthly or yearly. A monthly 99.9% commitment allows 43.8 minutes per month; a provider can burn that allowance twelve separate times and never owe you anything, despite nearly nine hours of cumulative downtime.

How much are service credits really worth?

Credits are the SLA’s remedy, and they are almost always a percentage of your bill for the affected service — not compensation for what the outage cost you. A worked example makes the gap concrete. Say you spend $10,000 a month on a service with a 99.9% SLA, and it suffers the full 8.77 hours of downtime in one month, dropping measured uptime to about 98.8%. A typical credit tier for that band is 10%, which returns $1,000. If your operation loses $2,500 per hour offline, those same hours cost you $21,925. The credit covers under 5% of the loss.

Three more credit mechanics to check, because in practice they decide whether you ever see the money:

• Claims are rarely automatic. Most SLAs require you to file within a fixed window, often 30 days, with your own evidence of the outage. No claim, no credit — so log availability independently.
• Credits apply to future invoices. They are a discount on continuing to use the service, not a check. If the outage drives you off the platform, the remedy can evaporate with you.
• Caps. Credits usually top out at some share of one month’s fee for that one service, no matter how bad the month was.

What do the exclusions hide?

The definitions and exclusions section is where an SLA is genuinely won or lost. Items we flag on every review:

• The definition of “unavailable.” Some SLAs count only full outages measured in five-minute blocks; a service failing 30% of requests all day may be contractually “available” throughout.
• Scheduled maintenance. Announced windows typically do not count as downtime. Check how much notice is required and whether windows are capped.
• Per-service scoping. The compute SLA does not cover the database, the DNS, or the identity service. Your application’s real availability is the product of every SLA in its dependency chain, so the weakest link sets the ceiling.
• Architecture prerequisites. Many infrastructure SLAs only apply if you deployed across multiple zones. Single-instance deployments often carry a lower commitment or none.
• Customer-caused and third-party events. Your misconfiguration, your code, upstream internet failures, and force majeure are all excluded — reasonably, but it narrows what is left.

It is worth saying that measured service — usage monitored, controlled, and reported — is one of the five essential cloud characteristics in NIST SP 800-145. An SLA is that principle applied to the provider’s own performance, so insist on the same transparency about their downtime that they apply to your usage.

How should you evaluate an SLA before signing?

Our short checklist: convert the percentage to minutes per period and compare it to what an hour of downtime costs you; confirm the measurement window (monthly vs. yearly) and granularity; list every service in your dependency chain and find its weakest SLA; read the credit table, the claim deadline, and the cap; and confirm which architecture choices the SLA requires of you. If provider-wide risk still worries you after that, the answer is usually architectural rather than contractual — we weigh that option in multi-cloud vs. single vendor.

FAQ

Are SLA terms negotiable?

On public list-price cloud services, rarely. At enterprise contract sizes, sometimes — credit percentages, caps, and reporting duties move before the uptime number does. Smaller managed providers negotiate far more than hyperscalers.

Does a higher SLA mean the service is more reliable?

Not by itself. The SLA is a financial commitment, not a measurement; a provider can offer 99.99% and simply budget for paying credits. Look at published incident histories and status pages for evidence of actual behavior, and treat the SLA as the floor of what they will admit to.

What is the single most overlooked clause?

The claim procedure. Teams assume credits arrive automatically; most contracts put the burden of detection, evidence, and a filing deadline on the customer. Independent uptime monitoring pays for itself the first time you need to prove an outage happened.

Uptime commitments differ more between providers than their marketing suggests — you can compare SLAs and support terms across vendors in our directory.