Error Budgets & SLOs ==================== Slide 1: Error Budgets & SLOs 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. On-screen text Error Budgets & SLOs Balancing reliability and feature velocity Slide 2: Service level objectives 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. On-screen text Service level objectives - Define target reliability percentages - Measure user-facing performance - Clarify what "good enough" looks like Slide 3: Error budgets 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. On-screen text Error budgets - Difference between perfect reliability and the SLO - Consumed as incidents and downtime occur - Helps prioritize fixes vs new features Slide 4: Using error budgets 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. On-screen text 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 Slide 5: Key takeaway 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. On-screen text Key takeaway Error budgets turn SLOs into actionable limits on risk, guiding when to push forward or stabilize.