SLA vs SLO vs SLI: Reliability Terms Explained With One Example

A customer asks, “What’s your uptime SLA?” Your engineers talk about SLOs in planning meetings. A vendor contract mentions SLIs in an appendix. The 3 acronyms sound interchangeable, and mixing them up can lead you to promise customers more than your systems can deliver.

They are not interchangeable. Each one plays a distinct role, and they stack on top of each other. The clearest way to understand them is to follow a single example from measurement to contract.

The 3 terms in one minute

Google’s Site Reliability Engineering book gives the standard definitions:

• SLI, service level indicator: a carefully defined quantitative measure of some aspect of the service you provide. It is a number you measure.
• SLO, service level objective: a target value or range for a service level measured by an SLI. It is the goal you set.
• SLA, service level agreement: an explicit or implicit contract with your users that includes consequences. It is the promise you make, with penalties if you break it.

The same book offers a handy test: if there is no explicit consequence for missing it, you are almost certainly looking at an SLO, not an SLA.

The running example: an online booking service

To see how the 3 fit together, picture an illustrative company that runs an appointment booking app used by salons and clinics. Its most important user journey is simple: a customer picks a time slot and clicks “Book.”

We will follow that “Book” button through all 3 layers.

Step 1: Choose the SLI (what to measure)

A good SLI reflects what users actually experience. OpenTelemetry’s observability primer makes this point directly: the best indicators measure the service from the user’s perspective, such as how quickly a page loads.

For the booking journey, the team picks 2 SLIs:

1. Availability SLI: the share of booking requests that complete successfully. - Formula: successful booking requests / total valid booking requests
2. Latency SLI: the share of booking requests that complete in under 1 second. - Formula: booking requests faster than 1 second / total valid booking requests

Notice what they did not pick. “Server CPU below 80%” is not an SLI here, because customers do not feel CPU. They feel failed bookings and slow pages.

The SRE book also recommends percentiles over averages for latency, because an average can hide a long tail of slow requests. Measuring “share of requests under 1 second” is a simple, percentile-friendly way to do this.

Step 2: Set the SLO (the internal target)

Next, the team decides how good is good enough. They look at recent performance, talk to the product owner and agree on:

• Availability SLO: 99.9% of booking requests succeed, measured over a rolling 30 days.
• Latency SLO: 99% of booking requests complete in under 1 second, over the same window.

Suppose the app handles about 1 million booking requests a month. Then:

• The availability SLO allows about 1,000 failed bookings per month.
• The latency SLO allows about 10,000 bookings slower than 1 second.

Those allowances are the error budget: the amount of unreliability the team can “spend” on releases, experiments and maintenance before it misses the target. When the budget is healthy, the team ships features. When it is nearly used up, reliability work comes first. Our guide to site reliability engineering explains error budget policies in detail.

Tips from the SRE playbook

The SRE book offers practical advice on setting SLOs:

• Do not simply lock in current performance. If you set the target to whatever you achieve today, you may commit to heroic effort just to stay there.
• Keep as few SLOs as possible. Cover the key user journeys. If an SLO never helps settle a priority debate, drop it.
• Keep a safety margin between internal SLOs and anything you promise externally.

Key takeaway: SLIs measure what users feel, SLOs set the bar your team aims for, and SLAs are the lower bar you promise customers. Always keep the SLA looser than the SLO so you notice and fix problems before they cost you money.

Step 3: Write the SLA (the customer promise)

Now a large clinic chain asks for a contractual uptime commitment. The business team, informed by engineering, offers:

• SLA: 99.5% monthly availability for booking requests. If availability falls below that, the customer receives a service credit on the next invoice, with larger credits for larger shortfalls.

Here is how the 3 layers line up in the example:

The gap between 99.9% and 99.5% is the safety margin. If the SLI drops to 99.8%, the team has missed its SLO and shifts to reliability work, but the company has not breached its contract. That early warning is the whole point of keeping the 2 separate.

How cloud providers write SLAs

Cloud SLAs show the same pattern in practice. The Amazon Compute SLA, for example, commits to a monthly uptime of 99.99% at the region level for instances deployed across 2 or more Availability Zones, and 99.5% for an individual instance. If AWS misses those commitments, customers can claim service credits, a percentage of the bill that grows as uptime falls further.

A few lessons from reading provider SLAs:

• Credits are the remedy, not compensation. A service credit is usually a share of what you paid for the affected service, not the cost of your lost business.
• Architecture affects eligibility. Higher commitments often apply only if you deploy across multiple zones, which ties directly to designing for high availability.
• You usually have to claim. Many SLAs require customers to submit a request within a set period.
• Exclusions matter. Scheduled maintenance, customer misconfiguration and events outside the provider’s control are typically excluded.

Your own SLAs cannot be stronger than the SLAs of the services you depend on, unless you add redundancy. If your app runs on a single instance with a 99.5% commitment, promising customers 99.99% is a risk. When comparing cloud platforms, our guide to AWS vs Azure vs Google Cloud covers broader differences.

Common mistakes to avoid

• Measuring the wrong thing. Server uptime can be 100% while users cannot log in. Measure user-facing behavior.
• Promising your SLO as your SLA. With no margin, every small incident becomes a contract breach.
• Too many SLOs. Dozens of targets dilute attention. Start with 1 to 3 per critical journey.
• Chasing 100%. It is unachievable in practice and freezes all change. Pick a target users would actually notice.
• Setting targets and never reviewing them. Revisit SLOs every quarter as the product and usage change.
• No agreed consequence for missing an SLO. Without an error budget policy, an SLO is just a dashboard.

Where to start

Use this 5-step checklist for your first SLIs, SLOs and SLAs:

1. List your 2 or 3 most important user journeys, such as sign-in, search, checkout or booking.
2. Define 1 or 2 SLIs per journey using data you already collect from load balancers, application logs or monitoring tools. Our comparison of observability vs monitoring explains where that data comes from.
3. Set SLOs a little below what users would notice, with product owners in the room.
4. Agree an error budget policy in writing: what the team does when the budget runs low.
5. Only then write SLAs, set looser than your SLOs, with clear credits, exclusions and claim processes reviewed by legal counsel. This is not legal advice.

The bottom line

SLIs, SLOs and SLAs form a chain. The SLI measures what users experience, the SLO sets the target your team manages to, and the SLA is the looser promise you make to customers with consequences attached. Keep the SLA below the SLO, measure what users actually feel, and use the error budget between them to decide when to ship and when to stabilize.

Sources

• Google SRE book: Service Level Objectives — definitions of SLI, SLO and SLA, percentile guidance and SLO-setting advice
• OpenTelemetry: Observability primer — SLIs from the user’s perspective
• Amazon Compute Service Level Agreement — example region-level and instance-level uptime commitments and service credits