Availability, SLAs, SLOs and SLIs

Think of it like this

Analogy

A bus company says its buses are “reliable”. That's meaningless until you define it. SLI: the share of buses that arrive within 5 minutes of schedule. SLO: the internal goal, 99% of buses each month. SLA: the promise on the ticket: if fewer than 95% arrive on time, monthly pass holders get a refund. The target is stricter than the promise, so the company notices problems before it owes refunds.

The problem it solves

“The site should never go down” isn't a requirement anyone can build or test. 100% is impossible, and each extra nine costs far more than the last: more redundancy, more regions, more engineering time. Without agreed numbers, teams either over-build or argue after every outage about whether things are “good enough”.

A real example

Example

A payment API’s promise to customers

A payment company promises shops 99.95% monthly availability in its SLA. That's about 22 minutes of downtime a month. If it misses, customers get service credits.

Internally, the team aims higher, at 99.99%, so a bad month still doesn't break the promise. Their SLI is simple: the share of payment requests that succeed within 1 second.

In March a bad deploy uses up most of the month's error budget in one afternoon. The rule they agreed on kicks in: new features pause, and the next two weeks go to safer deploys and better tests. When the budget is healthy, they ship as fast as they like.

How it works

The nines

Availability = successful time (or requests) ÷ total.

Availability	Downtime per year	Per month	Per week
99% (“two nines”)	3.65 days	7.3 hours	1.7 hours
99.9%	8.8 hours	43 minutes	10 minutes
99.95%	4.4 hours	22 minutes	5 minutes
99.99%	53 minutes	4.3 minutes	1 minute
99.999%	5.3 minutes	26 seconds	6 seconds

At four or five nines, humans can't respond fast enough; failover must be automatic.

SLI, SLO, SLA

SLI (indicator): what you measure. Good SLIs reflect user experience: the share of requests that succeed, the share served under 300 ms, the share of uploads processed within a minute.
SLO (objective): the target for an SLI over a window. “99.9% of checkout requests succeed over 30 days.”
SLA (agreement): a contract with customers, with consequences (usually service credits). It's set looser than the SLO.

Error budgets

If the SLO is 99.9%, you're allowed 0.1% failures, the error budget. Teams spend it on risk: releases, migrations, experiments. While budget remains, ship freely. When it's gone, freeze risky changes and fix reliability. It turns “reliability vs speed” arguments into a number both sides agree on.

Availability math

In series (A needs B and C): multiply. Three 99.9% components in a chain give about 99.7%.
In parallel (any one of two copies is enough): 1 − (chance both fail). Two independent 99% copies give 1 − 0.01 × 0.01 = 99.99%.

This is why redundancy works, and why every hard dependency lowers your best possible availability.

How systems reach high availability

No single points of failure: at least two of everything, in different availability zones.
Health checks and automatic failover for load balancers, databases and regions.
Multi-region for the highest targets, with global traffic routing.
Graceful degradation: when recommendations are down, show the page without them instead of an error.
Safe deploys: canary releases, gradual rollouts and fast rollback, since most outages follow changes.
Practice: game days and chaos experiments that break things on purpose.

Trade-offs

What you gain

Clear, shared targets instead of arguments.
Error budgets balance shipping speed with reliability.
SLIs based on user experience catch problems that server metrics miss.

What it costs you

Each extra nine costs much more: more regions, more automation, more on-call effort.
Badly chosen SLIs (like “server is up”) can look green while users suffer.
SLAs create financial exposure if set too tight.

When not to use it

Don't promise more nines than your dependencies (cloud services, payment providers) can give you.
Don't apply the same SLO to every feature; an internal admin page doesn't need four nines.

In the cloud

Multi-region traffic and failoverEvery major cloud sells this as a managed service, so you configure it rather than build it.

AWS2

Amazon Route 53 health checks and failover routing (opens vendor docs)
DNS answers change automatically when a region's health check fails.
AWS Global Accelerator (opens vendor docs)
Two static anycast IPs that route users over AWS's network to the nearest healthy region.

Azure2

Azure Front Door (opens vendor docs)
Global entry point that sends users to the nearest healthy backend region.
Azure Traffic Manager (opens vendor docs)
DNS-based failover and routing between regions.

Google Cloud2

Global external Application Load Balancer (opens vendor docs)
One anycast IP that serves users from backends in many regions and fails over automatically.
Cloud DNS routing policies (opens vendor docs)
Geolocation, weighted and failover DNS answers with health checks.

How you’d set it up

Two regions run the full stack; global routing sends users to the closest healthy one.

Route 53 failover
ALB in region 1 + region 2
App servers
Aurora Global Database

Interview questions

Try answering out loud first, then open the model answer.

What's the difference between an SLA, an SLO and an SLI?

Model answer

An SLI is a measurement, such as the percentage of successful requests. An SLO is the internal target for that measurement, such as 99.9% over 30 days. An SLA is an external contract that promises a level (usually looser than the SLO) and defines what happens if it's missed, often service credits. You alert on SLOs so you fix problems before breaching SLAs.

How would you design a service for 99.99% availability?

Model answer

That's about 4 minutes of downtime a month, so everything must fail over automatically. Run stateless services across at least three availability zones behind a load balancer, with headroom to lose a zone. Use a managed database with synchronous standby and automatic failover, or a multi-region database. Remove single points of failure, including DNS and secrets. Use timeouts, retries, circuit breakers and graceful degradation for dependencies. Deploy with canaries and automatic rollback. Monitor user-facing SLIs with burn-rate alerts, and test failover regularly. For more than that, go active-active across regions.

Your service calls five dependencies, each 99.9% available. What availability can you offer?

Model answer

If every call is required, roughly 0.999 to the fifth power, about 99.5%, before counting your own failures. To do better, reduce hard dependencies: cache responses so you can serve when a dependency is down, make non-essential calls optional (degrade gracefully), call redundant copies, and move work to async queues so a dependency outage delays work instead of failing requests.

Quiz

Pick an answer to see whether it’s right and why.

0 of 6 answered

Key terms

Availability: The share of time a system is up and answering correctly, often written as "nines" (99.9%).
SLA: Service level agreement. A promise to customers, usually with refunds if it's missed.
SLO: Service level objective. The internal target, such as 99.9% of requests succeed each month.
SLI: Service level indicator. The measured number an SLO is based on, such as the success rate.
Error budget: How much failure the SLO allows. 99.9% per month leaves about 43 minutes of budget.
Redundancy: Running extra copies of a component so one can fail without an outage.
Single point of failure: One component whose failure takes the whole system down.