Stop 13 · Site Reliability Engineering PracticesTopics · 1/8

SRE Principles & Error Budgets

In short

100% uptime sounds great, but chasing it means you never ship anything new. An error budget turns 'how reliable is enough?' into a number both developers and ops can agree on.

Applying Phase 11's SLO and error budget concepts as an organizing philosophy — when the error budget is healthy, ship features freely; when it's exhausted, prioritize reliability work over new features.

The mascot crosses days off a wall calendar while holding a jar with only a few coins left.

Think of it like this

The 75% attendance rule

Your college asks for 75% attendance. That leaves a quarter of classes you can miss without trouble. Spend them wisely and you're fine. Blow them all by October and you can't miss another class all term. An error budget is your allowed downtime, spent the same way.

Watch it happen

Spending a 99.9% budget over 30 days

Week 1

Week 2

Week 3

Week 4

1/5A 99.9% monthly target allows about 43 minutes of failure in 30 days. That's the whole budget.

The big ideas

What you need to know

SLO is the target

A service level objective, like '99.9% of requests succeed over 30 days', says how reliable users actually need you to be.

Budget is 100% minus SLO

With a 99.9% SLO, 0.1% of requests may fail. That allowance is the error budget you can spend on change.

It settles arguments

Budget left? Ship. Budget gone? Fix reliability first. The data decides, not whoever argues loudest.

SRE treats ops as software

Site reliability engineers solve operations problems with code: automation, better monitoring, safer deploys.

See it in code

Walk through the code

text

1SLO target          = 99.9% of requests succeed (30 days)2Error budget        = 100% - 99.9% = 0.1%3 4Requests this month = 50,000,0005Allowed failures    = 50,000,000 x 0.001 = 50,0006 7Failed so far       = 32,0008Budget used         = 32,000 / 50,000 = 64%9Budget left         = 36%  -> keep shipping, but carefully

1/3The budget is simply what the SLO leaves over. A stricter SLO means a smaller budget.

Request-based budgets work better than minute-based ones for busy APIs, because a slow hour at 3am and a slow hour at 8pm hurt different numbers of users.

Save yourself the pain

Common mistakes

Oops

Setting a 99.999% SLO because higher sounds better.

Do this instead

Pick what users truly need. Each extra nine costs far more effort, and users often can't tell 99.9% from 99.99%.

Oops

Defining an error budget but carrying on shipping when it runs out.

Do this instead

Agree in advance what happens when it's spent, like pausing risky releases, and stick to it.

Your mission

Budget your own project

~20 min

Quick check

Your service has a 99.9% SLO and the error budget is fully used with 10 days left. What does SRE practice suggest?

Go deeper

1Design a hypothetical policy: what happens to feature releases when an error budget is exhausted.
2Learn why this framework gives a data-driven, non-political way to balance speed and stability.
3Understand SRE isn't just 'ops with a new name' — it's a specific engineering discipline.