SLA vs SLO vs SLI: Definitions, Error Budgets and Examples

SLI, SLO and SLA are three layers of the same idea: measure reliability, set a target, and, optionally, promise it to customers. The terms were popularized by Google's Site Reliability Engineering books and are now standard across the industry.

Definitions

The relationship is: you measure SLIs, aim for SLOs, and promise SLAs. The SLA should always be looser than the SLO, so you have a safety margin before contractual penalties apply.

Service level indicators (SLIs)

A good SLI measures something users actually feel. It is usually expressed as a ratio of good events to total events, which gives a number between 0% and 100%. Common SLIs:

• Availability: successful requests divided by total requests, or successful checks divided by total checks.
• Latency: share of requests served faster than a threshold, such as 300 ms.
• Freshness: share of time data is no older than a threshold, useful for pipelines and dashboards.
• Correctness: share of responses that pass a validation check.

Avoid SLIs based on server metrics like CPU usage. They describe the machine, not the user experience.

Service level objectives (SLOs)

An SLO combines an SLI, a target and a window: "99.9% of checkout requests succeed, measured over a rolling 30 days." Guidelines for setting one:

1. Measure the SLI for several weeks before choosing a target.
2. Choose a target users would notice if you missed it, not 100%.
3. Prefer rolling windows (last 30 days) over calendar months, so a bad day at month-end does not reset artificially.
4. Keep the number of SLOs small, a few per service.
5. Review targets quarterly.

Service level agreements (SLAs)

An SLA is a legal and commercial document. It defines the metric, how it is measured, what is excluded (scheduled maintenance, customer-caused issues, force majeure), how customers claim compensation, and what the compensation is. Service credits, a percentage of the monthly fee, are the most common remedy. Because an SLA carries financial consequences, it is usually set below the internal SLO.

Error budgets

An error budget is the amount of unreliability an SLO permits: 100% minus the SLO. It turns reliability into a resource the team can spend. If the budget is healthy, the team can ship faster and take more risk. If it is nearly exhausted, the team slows down releases and focuses on stability.

Worked example: time-based

SLO: 99.9% availability over a rolling 30-day window.

Window:        30 days x 24 h x 60 min = 43,200 minutes
Error budget:  0.1% x 43,200 min       = 43.2 minutes (43 min 12 s)

Incidents this window:
  Deploy rollback    12 min
  Database failover   9 min
  Total              21 min

Budget consumed:   21 / 43.2  = 48.6%
Budget remaining:  43.2 - 21  = 22.2 minutes

Half the budget is gone with time still left in the window. A reasonable policy is to keep shipping but require extra review for risky changes until the window rolls forward.

Worked example: request-based

SLO: 99.9% of API requests succeed over 30 days. The service handles 20,000,000 requests in that period.

Error budget:   0.1% x 20,000,000 = 20,000 failed requests
Failed so far:  14,500
Remaining:       5,500 (27.5% of the budget)

Request-based budgets are fairer for services with uneven traffic: an outage at 3 a.m. with little traffic consumes less budget than one at peak.

Burn rate

Burn rate is how fast you are consuming the error budget relative to the rate that would exactly exhaust it at the end of the window. A burn rate of 1 means you will use the whole budget by the end of the window. A burn rate of 10 means a 30-day budget would be gone in 3 days. Alerting on high burn rates catches serious problems quickly while ignoring small, slow consumption.

How to measure in practice

• External uptime checks measure availability as users see it from outside, including DNS, TLS and network problems that server logs miss. Check interval limits precision: a 1-minute interval cannot see a 20-second outage.
• Server or load balancer logs give request-based SLIs with full traffic coverage, but miss failures that happen before requests reach you.
• Real-user monitoring captures actual user experience in browsers and apps.

Many teams combine external checks for availability with logs for request success and latency. Uptime Tracker measures time-weighted availability from external checks, with outages counted from the first failed check and maintenance windows excluded. The Team plan adds SLOs with error budget tracking. See the nines table for the downtime each target allows, or use the uptime calculator.

Putting it together: one service, three layers

Here is how the three terms fit together for a hypothetical public API:

The gap between the 99.95% SLO and the 99.9% SLA gives the team about 21 minutes per month of warning before customers are owed credits. When the error budget is half spent, the team reviews risky releases; when it is gone, feature releases pause.

Common mistakes

• Setting the SLA equal to the SLO, leaving no margin.
• Targeting 100%, which leaves no room for change and is unachievable.
• Measuring only the homepage while customers depend on the API.
• Defining many SLOs that nobody reviews.
• Not agreeing in advance what happens when the error budget runs out.