What are SLIs, SLOs, SLAs, and error budgets — and how do they actually change engineering decisions?

#Four terms that are easy to confuse and important to keep straight

These four terms get used almost interchangeably in casual conversation, and interviewers specifically probe whether you know they aren't the same thing, because the differences are exactly where the practical decision-making power lives.

SLI — Service Level Indicator. A directly measured, quantitative signal of user-facing behavior. "Proportion of HTTP requests that returned a non-5xx status," "proportion of requests served in under 300ms," "proportion of messages processed within 5 seconds of being enqueued." An SLI is a measurement, not a target — it's the raw number you'd compute from your metrics right now.

SLO — Service Level Objective. An internal target for an SLI over a defined window: "99.9% of requests return successfully, measured over a rolling 30-day window." The SLO is where a business decision (how reliable does this actually need to be, given cost and user expectations) turns into an engineering target. It is internal — nobody outside the company is contractually promised this number, and it's deliberately set a bit stricter than any external promise.

SLA — Service Level Agreement. An external, usually contractual, commitment made to customers, with real consequences attached — service credits, refunds, termination rights — if it's breached. A typical pattern is SLA = 99.5% while the internal SLO = 99.9%: the gap between them is a deliberate safety margin, so that the moment you'd start being at real risk of the contractual consequence, your internal alerting has already been screaming for a while.

Error budget. The mathematical complement of the SLO: 100% − SLO target, converted into a concrete quantity over the SLO's window — a number of allowed failed requests, or a number of allowed minutes of downtime. It's the budget you're explicitly allowed to spend on risk: deploys that might go wrong, experiments, infrastructure changes, calculated risks that trade a little reliability for velocity or learning.

#Turning 99.9% into a number you can actually spend

For a 99.9% monthly availability SLO evaluated over a 30-day window: total minutes in the window are 30 × 24 × 60 = 43,200. The allowed downtime is 0.1% of that, which comes out to roughly 43 minutes for the entire month. That's the error budget, expressed as a duration. For a request-success SLO instead of an availability SLO, express it as a request count: at 10 million requests/month, a 99.9% target allows roughly 10,000 failed requests over the month.

#A concrete month: spending the budget, and running out of it

Say checkout-api has a 99.9% monthly availability SLO (≈43 minutes of allowed downtime) and a customer-facing SLA of 99.5% with financial credits attached. Early in the month, a bad deploy causes a 25-minute outage before it's rolled back. That single incident consumes about 58% of the entire monthly error budget (25 of ~43 minutes) — and it's only the fifth of the month.

This is where an error budget policy — an agreed-upon, pre-written set of consequences, not an ad hoc argument in a Slack thread — kicks in. A typical policy might say: once more than 50% of the monthly budget is spent, non-essential feature releases pause and the team's top priority shifts to reliability work (root-causing the deploy failure, adding a canary stage, improving rollback speed); once the budget is fully exhausted, all further production changes require explicit sign-off from an SRE or engineering lead, and a postmortem becomes a mandatory gate before any additional deploys, not an optional nicety.

Contrast that with a quiet month where the team hasn't touched more than 5% of the budget by day 25: that's a real, data-backed signal that the team can safely take on more risk — ship a bigger migration, turn on a risky feature flag for more users, defer some hardening work — because they have margin to burn if something goes slightly wrong.

#Why this changes real engineering decisions, not just dashboards

Before error budgets, the argument between "ship the feature" and "fix reliability" is usually a political one — whoever has more organizational weight in the room wins, independent of the actual data. An error budget converts that into an objective, pre-agreed number both product and engineering already signed off on: there's no negotiation mid-incident about whether a freeze is "fair," because everyone agreed to the policy before there was an incident to be emotional about.

It also works in the other direction, which people forget: an error budget isn't just a stick, it's explicit permission to take risks when you have margin. A team sitting on 95% of its untouched error budget with two weeks left in the window has a legitimate, data-backed case for shipping something bigger and riskier than usual — the budget exists precisely so that "how much risk can we take on right now" has an actual answer instead of being a vibe.

Finally, error budgets give engineering a defensible way to push back on unreasonable external asks: if sales wants to promise a customer a 99.99% SLA and the current SLO, measured honestly, is 99.9%, the error budget math makes the gap concrete and non-negotiable — you'd need to invest in specific reliability work (multi-region failover, better testing, slower rollout gates) before that number is credible, not just say yes because it sounds like a good number in a sales deck.

#The four terms, side by side

🧠 Check your understanding
0/3 · 0/3 answered
1. A team has an SLO of 99.9% monthly availability and an SLA of 99.5% with the same customers. Why is the SLO deliberately stricter than the SLA?
SLOs are always required to be higher than SLAs by industry regulationThe gap is a safety margin: internal alerting and error-budget policies trigger well before the company would actually be in breach of the contractual SLAThere is no meaningful difference between the two numbers in practiceIt's a typo — SLA and SLO should always be set to the same number
2. A service has a 99.9% monthly availability SLO. A single incident causes a 25-minute outage out of an approximately 43-minute monthly error budget. What is the appropriate engineering response under a typical error budget policy?
Nothing — a single incident is always within acceptable limits regardless of budget consumedRoughly 58% of the monthly budget is now spent, which should trigger a pre-agreed policy response, such as pausing non-essential feature work and prioritizing reliability fixes for the rest of the monthThe SLO should immediately be lowered to make the incident compliantThe incident should be hidden from the SLO calculation since it was caused by a deploy, not organic traffic
3. What is the main practical benefit of having an explicit, pre-agreed error budget policy, compared to just discussing reliability vs. feature work case by case?
It allows the SLA to be renegotiated automatically with customersIt guarantees the service will never have an outage againIt removes the need to measure any SLIs at allIt converts what would otherwise be a political, in-the-moment negotiation into an objective decision based on a number everyone already agreed to before an incident happened