SLA vs SLI vs SLO: What Your Cloud Provider Actually Promises

August 12, 2026

The three letters that appear on every cloud SLA page are not synonyms. SLA, SLO, and SLI describe three different things: what you signed, what the provider aims for, and what actually gets measured. Most engineers use them interchangeably, and the provider wins the argument because the measurement definition, the SLI, is where the fine print hides. This post pulls the definitions straight from the current AWS, Azure, Google Cloud, and DigitalOcean SLA documents so you can read your own contract and know exactly when a credit is owed.

The three letters, in plain terms

An SLA is the legal document. It is the agreement between you and the provider that names a target and the compensation if that target is missed. It is the only one of the three that binds anyone.

An SLO is the target. It is the number inside the SLA, expressed as a percentage like 99.9% or 99.99%. It tells you how available the provider commits to being in a billing cycle. The same service can carry several SLOs depending on how you run it.

An SLI is the measurement. It is how the provider actually calculates availability from raw data, such as the number of failed requests divided by total requests, or the minutes a resource had no connectivity. This is the definition that decides whether a real outage counts as a breach. Two providers can both promise 99.99% and measure completely different things.

The consequence you care about, the service credit, only exists in the SLA. The credit percentage is fixed in the agreement. But whether you ever receive it depends entirely on the SLI, because the SLI decides if the SLO was missed.

The SLI is where the loophole lives

Every provider measures downtime differently, and the differences are not cosmetic. They decide whether a long outage produces a credit or nothing at all.

AWS S3 measures uptime by error rate. Monthly Uptime Percentage is 100% minus the average of the Error Rate across each five minute interval in the billing cycle. The Error Rate for an interval is the number of internal server errors returned (status InternalError or ServiceUnavailable) divided by the total requests in that interval. If you make no requests in a five minute window, that window is treated as a zero error rate. What that means in practice: if you are not sending traffic during the outage, the outage may not register against your account at all.

GCP takes a different route. Its Compute Engine SLA counts only full minutes of downtime. A period of one or more consecutive minutes counts as a Downtime Period, but partial minutes and intermittent blips under one minute do not count. For instances in multiple zones, downtime means all of your running instances lose connectivity. Two of three zones failing is not a breach if the third still answers.

Azure and DigitalOcean measure availability in minutes per instance. For Azure Virtual Machines, Monthly Uptime Percentage is Maximum Available Minutes minus Downtime, divided by Maximum Available Minutes, across the instances in your deployment. DigitalOcean calculates the same ratio per individual Droplet.

What each provider actually commits to

The promised number differs by provider, service, and how you deploy. A single EC2 instance does not carry the same SLO as a multi-AZ fleet, and DigitalOcean gives every Droplet the same commitment regardless of redundancy.

The sentence to remember when you open any SLA page: "Monthly Uptime Percentage" is defined somewhere in that document, and that definition, not the headline number, decides whether you get paid. If the outage does not match the SLI's definition of downtime, the SLA never triggers.

The credit schedules tell you what the outage is worth

Each provider publishes a ladder of credit percentages that scales with how far availability fell. The banding is broadly similar, with small differences worth knowing.

DigitalOcean is the outlier. Its Droplet SLA pays 100% of the affected Droplet's charges for any month that dips below 99.99%, with no tiers at all. That sounds generous until you read the scope: the credit applies only to the specific Droplet that was down, so a $6 instance earns $6.

How to read an SLA without a lawyer

Microsoft publishes a five pass method for reading any service agreement, and it applies to AWS and GCP contracts just as well as Azure's. The order matters.

Start with the definitions section. The terms "valid request", "downtime", and "billable minutes" control everything else, and a narrow definition of downtime means the effective coverage is narrower than the percentage suggests. A 99.9% SLA does not guarantee the service is always available. It means the service stayed within its documented definition of failure for the billing period.

Next, check how availability is measured. Time based measurement tracks whether the resource was up in each interval. Request based measurement, like S3's error rate, tracks the ratio of failed requests to valid ones. The same outage produces different numbers depending on the method, and aggregation over a whole month means a short outage may not move the needle enough to trigger a credit.

Then look at prerequisites and exclusions. Many SLAs only apply when you meet conditions: running instances across multiple availability zones, using a specific storage tier, or implementing retry logic. Scheduled maintenance, force majeure, and anything caused by your own application code are almost always carved out. If an outage traces back to your side, the SLA never engages.

Finally, confirm the claim window. AWS requires credit requests within the end of the second billing cycle after the incident. GCP wants notification within 60 days of eligibility for Compute Engine. DigitalOcean asks for a contact within two billing cycles of the outage month. Every provider states the window in its SLA, and missing it forfeits the credit.

The bottom line for your workload

Before you design around a headline number, check the three definitions in the SLA for the exact service you run. Ask what counts as downtime, what measurement method is used, and what you must deploy to qualify for the SLO you are assuming. Most teams that assume they are covered at 99.99% discover they only qualified for 99.5% because they ran single instances.

Pull the SLA page for the service that carries your most expensive workload right now. Read its definitions section and the claim window, note the date it closes, and set a reminder. That single page holds the number that decides whether your next outage costs you nothing or earns you a credit.