SLOs and Error Budgets in Plain English

Every technology team wants reliable services. Every product team wants new features shipped quickly. These goals pull against each other: change is the most common cause of failure, so moving faster tends to mean more incidents, and focusing on stability tends to slow delivery down.

Service level objectives, and the error budgets that come with them, give teams a shared, measurable way to balance the two. The approach was popularised by site reliability engineering (SRE) practice, but the ideas are simple and useful for any team that runs a service people depend on.

The vocabulary

Four related terms come up again and again.

SLI: service level indicator

A measurement of how a service is performing from the user's point of view. Common examples:

• Availability: the proportion of requests that succeed.
• Latency: the proportion of requests answered within a certain time.
• Quality or correctness: the proportion of results that are accurate or complete.
• Freshness: how up to date data is, for example in a reporting system.

The best SLIs reflect what users actually experience, not internal measures such as server CPU.

SLO: service level objective

A target for an SLI over a period of time. For example: "99.9% of requests to the checkout service succeed, measured over 30 days." It is an internal goal that the team commits to.

SLA: service level agreement

A contractual promise to customers, usually with consequences such as service credits if it is broken. SLAs should be less strict than SLOs, so the team has room to respond before the contract is breached.

Error budget

The amount of unreliability the SLO allows. If your SLO is 99.9% availability over 30 days, your error budget is the remaining 0.1%: roughly 43 minutes of failed requests in a month. The budget can be "spent" on failures caused by releases, experiments, maintenance or unexpected incidents.

Why 100% is the wrong target

It is tempting to aim for perfect reliability. In practice, 100% is almost never the right goal:

• Users cannot tell the difference between very high reliability and perfect reliability, because their own devices, networks and other services fail more often than that.
• Each extra "nine" costs much more than the last, in engineering effort, infrastructure and slower change.
• A 100% target leaves no room for change. Any release carries some risk, so a perfect target effectively forbids improvement.

The right SLO is reliable enough that users are happy, and no more.

How error budgets change the conversation

Error budgets turn arguments about reliability into simple decisions:

• If the budget is healthy, the team can release freely, run experiments and take reasonable risks.
• If the budget is nearly spent, the team slows down, focuses on stability, and holds back risky changes until reliability recovers.
• If the budget is repeatedly exhausted, the SLO, the architecture or the release process needs attention.

This gives product and engineering teams a shared rule agreed in advance, rather than negotiating each release on gut feel. It also makes reliability work visible and legitimate: when the budget is spent, improving stability is the priority, not a distraction from features.

Setting your first SLOs

1. Pick one important service. Start where reliability matters most to users or the business.
2. Identify the user journeys that matter. For an online shop: browsing, adding to basket, checking out.
3. Choose one or two SLIs per journey. Usually availability and latency.
4. Look at historical performance. Set an initial SLO close to what you achieve today, so it is realistic.
5. Agree what happens when the budget runs low. Write down the policy: for example, release freeze for non-urgent changes, and an incident review.
6. Review after a few months. Tighten or loosen the SLO based on user feedback and business needs.

Common pitfalls

• Measuring the wrong thing. SLIs based on internal metrics rather than user experience can show green while users suffer.
• Too many SLOs. A handful per service is plenty. Dozens become noise.
• No consequences. If nothing changes when the budget is exhausted, the SLO is just a number on a dashboard.
• Alerting on everything. Alert on threats to the SLO, such as burning through the budget quickly, rather than on every individual metric.
• Setting SLOs in isolation. Product owners and business stakeholders should agree them, not just engineers.

SLOs and delivery performance

SLOs connect naturally with software delivery metrics. Change failure rate and time to restore service, two of the metrics described in our article on DORA metrics, directly affect how quickly a team spends its error budget. Teams that deploy small changes safely and recover quickly can move faster without exhausting their budgets.

How mature is your reliability practice?

Updated October 2026: we have added an Observability & SRE assessment. It covers service level objectives, telemetry and instrumentation, alerting and on-call, incident response and learning, toil and capacity, and reliability culture and release safety.

The DevOps / CI-CD assessment covers the delivery practices that make safe, frequent releases possible.

Frequently asked questions

What is a typical SLO?

There is no universal figure. Many user-facing services use availability SLOs between 99% and 99.95%, depending on how critical they are and what users expect. Start from current performance and user needs rather than copying another organisation's target.

Do SLOs only apply to software?

The idea applies to any service with users: internal IT services, data pipelines, even operational processes. Wherever you can measure the user experience and agree an acceptable level, an SLO can help.

Who should own SLOs?

The team that runs the service usually owns its SLOs, agreed with product owners and stakeholders who understand what users need.