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

An SLI is a measurement, an SLO is a target for that measurement, and an SLA is a promise to customers with consequences attached. For example: the SLI is "percentage of successful health checks," the SLO is "99.95% over a rolling 30 days," and the SLA is "99.9% monthly availability, or you receive a 10% service credit." The three build on each other: you cannot write a sensible SLA without an SLO, and you cannot track an SLO without a reliable SLI.

The terms were popularized by Google's Site Reliability Engineering book (O'Reilly, 2016), but they are useful well beyond large companies. A two-person SaaS or an agency running client sites can use the same vocabulary to decide when reliability work should take priority over new features.

The three terms side by side

SLI: what you measure

A service level indicator is a ratio of good events to total events, expressed as a percentage. Writing it as a ratio keeps it comparable over time and makes the target easy to reason about.

Common SLIs for websites and APIs:

• Availability: successful checks / total checks, or successful requests / total requests.
• Latency: requests served faster than a threshold / total requests (for example, under 500 ms).
• Correctness: responses containing the expected content / total responses.
• Freshness: for background jobs, runs that completed on schedule / expected runs.

Two practical rules make an SLI useful:

1. Define "good" precisely. "Up" should mean a specific thing, such as an HTTP status below 400, received within 10 seconds, with the word "Dashboard" present on the page. A server that returns 200 OK with an empty page is not up for your users.
2. Decide where you measure. Server logs see every request but miss failures that happen before traffic reaches you, such as DNS, TLS or load balancer problems. An external check sees what a visitor sees but only samples the service at intervals. Many teams use external checks for availability and server logs for latency.

Interval matters for check-based SLIs

If you measure availability with an external monitor, your resolution is limited by the check interval. With checks every 5 minutes, a 2-minute outage between checks may never be recorded, and a single failed check can count as 5 minutes of downtime. With checks every minute, the measured number gets much closer to reality. Neither is wrong, but write the method down next to the SLO so everyone reads the number the same way.

SLO: the target you aim for

A service level objective is the value an SLI should reach over a defined window. A complete SLO has three parts:

• The SLI it applies to
• The target, for example 99.9%
• The window, usually a rolling 30 days or a calendar month

Availability SLO: at least 99.9% of 1-minute health checks to https://app.example.com/health succeed over a rolling 30 days.

Choosing a target

Start from what users actually need, not from the highest number you can imagine. Each extra nine cuts the allowed downtime by a factor of ten and usually costs much more to achieve. A rolling 30-day window contains 43,200 minutes, which gives these allowances:

These figures use a 30-day window. For calendar months and years, see uptime percentage explained, or plug any number into the uptime calculator.

A few guidelines:

• Do not promise more than your dependencies deliver. If your app depends on one database server and one hosting region, it cannot be more available than those two combined.
• Start with a target you already meet most months. Look at the last three months of data and set the SLO slightly below your typical result. Tighten it later.
• Keep the list short. One availability SLO and one latency SLO per user-facing service is enough for most small teams.

Error budgets: turning the SLO into decisions

The error budget is 100% minus the SLO. With a 99.9% SLO, the budget is 0.1% of the window: about 43 minutes per 30 days, or 1,000 failed requests per million.

The budget is what makes an SLO actionable. Track how much of it has been spent:

budget_minutes = (1 - 0.999) * 30 * 24 * 60   # 43.2
spent          = 20                              # minutes down so far
remaining_pct  = (budget_minutes - spent) / budget_minutes * 100   # about 53.7%

If 20 minutes of downtime happen in the first week, you have used about 46% of the month's budget in a quarter of the time. That is a signal, not a disaster. A simple policy might be:

• More than 50% left: ship as normal.
• Less than 50% left: review recent incidents and fix the top cause before risky releases.
• Budget exhausted: freeze non-urgent deploys until the window recovers, and spend the time on reliability.

Agree on this policy before you need it. Deciding during an outage whether to freeze releases leads to arguments; deciding in advance leads to a quick check of a number.

SLA: the promise with consequences

A service level agreement is a contract, or a section of one, that commits you to a level of service. A typical SLA states:

• The metric and target, for example 99.9% monthly availability.
• How it is measured, including which components count and from where.
• Exclusions, such as announced maintenance, customer-caused issues and failures of third parties outside your control.
• Remedies, usually service credits on a sliding scale.
• How to claim, often requiring the customer to request credits within a set period.

An illustrative credit table might look like this. It is an example, not a standard:

Why the SLA should be looser than the SLO

If your SLA and SLO are both 99.9%, the first time you notice a problem is the moment you owe customers money. Keeping the internal SLO stricter, for example 99.95% behind a 99.9% SLA, gives you a margin: missing the SLO triggers engineering work, and only a much worse month triggers credits.

Have someone with legal knowledge review any SLA you publish. The definitions of "downtime" and the exclusions matter more than the headline number.

A starter set for a small SaaS or website

If you have nothing today, this is a reasonable first version you can set up in an afternoon:

1. Availability SLI: an external HTTPS check of your main app URL or /health endpoint every minute, counting a check as good when it returns a status below 400 and contains an expected keyword.
2. Availability SLO: 99.9% over a rolling 30 days.
3. Latency SLI and SLO: 95% of requests served in under 800 ms, measured from your server or CDN logs over 30 days.
4. Job freshness: a heartbeat from each critical cron job, with an SLO such as 99% of scheduled runs completing on time.
5. Visibility: a public status page so customers can see current state and incident history. See how to create a status page.
6. Review: a 15-minute monthly look at budget spent and the incidents that spent it.

An uptime monitor such as PingRobot covers points 1 and 4 out of the box: HTTP and keyword checks every minute on the Pro plan, heartbeat monitors for cron jobs, failures re-checked from a second region before an email alert goes out, and a public status page. If you are new to the mechanics, start with what is uptime monitoring.

Common mistakes

• Measuring only from the server. Logs cannot see a DNS failure or an expired certificate, because those requests never arrive.
• Counting "200 OK" as success. Error pages and blank pages often return 200. Check for content too.
• Too many SLOs. Twenty targets nobody reviews are worse than two that drive decisions.
• Choosing 99.99% because it sounds good. About 4 minutes of downtime per 30 days leaves no room for a single slow deploy rollback.
• Leaving the measurement method undocumented. "99.9%" means little unless everyone knows the interval, locations and definition of failure behind it.

Start monitoring free — 10 monitors, no credit card.