How to Read a Cloud SLA: Uptime, Credits and Exclusions

Your app went down for 2 hours last Tuesday because a cloud region had a bad day. Your customers were angry, your team lost an evening, and someone asks: “Doesn’t our provider guarantee 99.99% uptime? Don’t they owe us?” The answer is usually “a little, if you ask in time, and only if you deployed the right way.”

A cloud service level agreement (SLA) is a contract, and like any contract the headline number matters less than the definitions and the fine print. This guide shows you how to turn uptime percentages into minutes, read a service credit table, find the exclusions that matter and file a claim, using the Amazon EC2 SLA as a worked example.

What a cloud SLA is (and what it isn’t)

A cloud SLA is the provider’s written promise about availability for a specific service, plus the remedy if they miss it. Each service usually has its own SLA: compute, storage, databases and load balancers all differ.

It is useful to separate 3 terms:

• SLA: the external, contractual promise with a remedy attached.
• SLO: an internal target your team aims for, usually stricter than any SLA you give customers.
• SLI: the actual measurement, such as the percentage of successful requests.

Our explainer on SLA vs SLO vs SLI covers these in depth. For this guide, what matters is that a provider’s SLA is not a forecast of how reliable the service will be. It is a statement of when the provider will give you money back.

Key takeaway: An SLA is a refund policy, not a reliability guarantee. The provider promises a bill credit if it misses a target, not that your application will stay up.

How to read a cloud SLA in 7 steps

Work through the SLA for each service your application depends on, in this order.

Step 1: Convert the uptime percentage into downtime

Percentages close to 100 all look the same. Minutes don’t. Here is what common targets allow in a 30-day month and a 365-day year.

Most cloud SLAs measure uptime per calendar month, so the monthly column is the one that matters for credits. A single 40-minute outage would keep a 99.9% service within its SLA, while breaching a 99.99% one.

Step 2: Check what deployment qualifies for the headline number

The biggest number on the SLA page usually applies only to a specific architecture. A single virtual machine almost never gets the top tier.

The Amazon EC2 SLA has 2 levels:

• Region-level: 99.99% monthly uptime, for instances running in 2 or more Availability Zones in the same region.
• Instance-level: 99.5% monthly uptime for each individual instance.

Microsoft’s SLA for Virtual Machines follows the same pattern. It offers its highest uptime commitment when you run 2 or more VMs across 2 or more availability zones, a lower one for VMs in an availability set, and a lower one again for a single VM, which also depends on the disk type. Microsoft publishes these in its Service Level Agreements for Online Services document. Google Cloud’s Compute Engine SLA likewise sets a higher commitment for instances in multiple zones than for a single instance.

If you run one VM in one zone, read the single-instance line, not the headline.

Step 3: Read the definition of “unavailable”

This is where SLAs get specific. Downtime only counts if it matches the provider’s definition.

In the EC2 SLA, an instance is “unavailable” when it has no external connectivity. For the region-level SLA, all your running instances in 2 or more Availability Zones must concurrently have no external connectivity. If one zone fails and your instances in the other zone keep running, that does not count as region-level unavailability.

Other things to look for in the definitions:

• Minimum duration. Some SLAs only count an interval as down if errors persist for a set number of minutes.
• Error rate thresholds. Storage and API services often define downtime by error rate, not total outage.
• Degraded performance. Slow is usually not “down.” If latency matters to you, the SLA probably won’t help.
• Measurement source. The provider’s monitoring, not yours, typically decides what counts.

Step 4: Read the service credit table

When the provider misses its target, you get a service credit: a percentage of that service’s monthly charges, applied to a future bill. The EC2 SLA uses this schedule for both levels:

AWS also says it won’t charge for a single instance that is unavailable for more than 6 minutes in a clock hour, applied automatically.

Read the credit terms closely:

• Credits are against the affected service only. If your EC2 bill was $2,000 and you qualify for 10%, the credit is $200, even if the outage cost you far more in sales.
• Credits apply to future payments. The EC2 SLA says credits apply against future EC2 payments, and AWS may at its discretion issue them to the card used for the billing cycle. They are not refundable or transferable.
• Upfront payments are excluded. The EC2 SLA excludes one-time payments, such as upfront Reserved Instance fees, from the bill used to calculate credits.
• Minimum amounts. AWS only issues credits over $1 USD.

Step 5: Find the exclusions

Every SLA lists conditions under which downtime does not count. The EC2 SLA excludes unavailability caused by:

• Factors outside AWS’s reasonable control, including force majeure and internet problems beyond the EC2 demarcation point
• Your own actions or inactions, such as not responding to resource health concerns
• Your equipment, software or other technology
• Suspension or termination of your right to use the service

Across providers, also expect exclusions for scheduled maintenance windows, preview or beta features, free tiers and misconfiguration on your side. That last point ties to the cloud shared responsibility model: if your security group blocks traffic, that is your outage, not theirs.

Step 6: Note the claim process and deadline

Credits are rarely automatic. You usually have to file a claim with evidence before a deadline.

For EC2, you open a case in the AWS Support Center, and the claim must be received by the end of the second billing cycle after the incident. It must include the dates and times of each incident, the affected region (and Availability Zone for instance-level claims), resource IDs and supporting logs. AWS says a claim missing the required information is disqualified.

Put the deadline in your incident runbook. If you only remember to file after the quarterly finance review, you may already be too late. Our guide to creating an incident response plan shows where a step like this fits.

Step 7: Check the “sole remedy” clause

Most cloud SLAs say service credits are your sole and exclusive remedy for unavailability. The EC2 SLA uses that language, unless your agreement says otherwise. In practice, that means you can’t recover lost revenue or other damages through the SLA. Large enterprises sometimes negotiate custom terms, but standard self-service accounts get the published SLA.

This is not legal advice. For contract questions, talk to your attorney.

Composite SLAs: why your app is less available than any one service

Your application depends on several services at once: compute, a database, a load balancer, DNS and storage. If they fail independently and all are required, the combined availability is roughly the product of each one.

For example, a VM layer at 99.95% and a database at 99.99% give about 99.94% combined (0.9995 x 0.9999). Add more dependencies and the number keeps dropping. Redundancy across zones or regions raises it again, which is why the top-tier SLAs require multi-zone deployments.

A quick SLA review checklist

Where to start

1. List the 5 to 10 cloud services your main application depends on.
2. Open the current SLA for each and note the uptime tier that matches how you actually deploy.
3. Convert each to monthly downtime and estimate your composite availability.
4. Compare that with what you promise your own customers, and close the gap with multi-zone design, backups and monitoring.
5. Add credit claim steps and deadlines to your incident runbook.

If you are still choosing a provider, SLA terms are worth comparing alongside price and features; see our AWS vs Azure vs Google Cloud comparison. Providers update SLAs from time to time, so always read the current version on the provider’s site.

Conclusion

A cloud SLA tells you how much downtime a provider tolerates before it owes you a credit, and how small that credit is. Read it in this order: convert the percentage to minutes, confirm which deployment qualifies, check the definition of downtime, review the credit table, scan the exclusions and record the claim deadline. Then accept the main lesson: your availability depends on your architecture, not on the provider’s refund policy.

Sources

• Amazon EC2 Service Level Agreement — region-level and instance-level uptime, credit tiers, exclusions, claim deadline and sole remedy terms
• Microsoft Service Level Agreements for Online Services — official Azure SLA documents, including Virtual Machines
• Microsoft Learn: Reliability in Azure Virtual Machines — how availability zones and availability sets raise the VM SLA
• Google Cloud: Building blocks of reliability — availability targets for single-zone and multi-zone designs