Back to lesson

Error Budgets & SLOs

Slide 1: Error Budgets & SLOs

On-screen

Error Budgets & SLOs

Balancing reliability and feature velocity

Narration

Anna: Imagine you promised your app would be available 99.9% of the time. That still allows roughly nine hours of downtime a year.
Greg: Site Reliability Engineering, or SRE, turns those promises into math we can track. The key tools are service level objectives, or SLOs, and the error budgets tied to them.
Anna: By defining how reliable a service must be, we can decide when it's safe to launch new features and when it's time to pause and fix instability.

Slide 2: Service level objectives

On-screen

Service level objectives

  • Define target reliability percentages
  • Measure user-facing performance
  • Clarify what "good enough" looks like

Narration

Anna: A service level objective is basically a reliability target, like "respond to user requests within two seconds 99% of the time." It sets clear expectations.
Greg: For non-technical folks, think of an SLO as a promise to customers. If we hit that goal, users stay happy. If we miss it, they notice glitches or slow pages.
Anna: We monitor these objectives continuously so we know if the service is drifting away from the acceptable range before customers complain.

Slide 3: Error budgets

On-screen

Error budgets

  • Difference between perfect reliability and the SLO
  • Consumed as incidents and downtime occur
  • Helps prioritize fixes vs new features

Narration

Anna: An error budget is the small slice of allowable failure built into an SLO. If our target is 99.9% uptime, that gives us about forty minutes of downtime each month.
Greg: As outages or performance issues occur, we "spend" that budget. When it's gone, engineering focuses on reliability work instead of shipping new features.
Anna: This approach keeps everyone aligned. Product managers see how instability eats into development time, while engineers know exactly when to slow their release pace.

Slide 4: Using error budgets

On-screen

Using error budgets

  • Track burn rate over time
  • Slow releases when the budget runs low
  • Foster data-driven reliability conversations
Green: keep shipping. Amber: slow risky changes. Red: freeze and recover.
100% 25% 0% Week 2 Week 6 Week 12 Healthy Caution: slow down Freeze and recover steady burn spiky burn

Narration

Anna: Error budgets aren't just for ops teams. They spark conversations about risk across the organization.
Greg: When the budget burns down faster than expected, it's a sign our releases might be too risky or our SLO is unrealistic.
Anna: Teams can agree to slow deployments, add more testing, or even adjust the SLO if customer impact warrants it. The data helps remove emotion from those decisions.

Slide 5: Key takeaway

On-screen

Key takeaway

Error budgets turn SLOs into actionable limits on risk, guiding when to push forward or stabilize.

Narration

Anna: The real win is shared language. SLOs and error budgets help teams quantify acceptable risk instead of arguing about perfection.
Greg: They also create breathing room. When you're under budget, you can innovate quickly. When it's nearly spent, stability becomes the priority.
Anna: By treating reliability like any other feature, SRE practices keep users happy and developers focused on the right work at the right time.