A team keeps blowing its error budget. First steps?

WHAT THIS TESTS Whether you approach chronic reliability problems as an engineering and partnership problem solved with data and a blameless culture, not as policing or blame.

A GOOD ANSWER COVERS First, diagnose where the budget is actually going. Use monitoring, SLI breakdowns, and recent postmortems to attribute the burn: which endpoints, which error classes, which incidents, and whether it is a few large outages or constant low-level errors. Look at deploy correlation, change failure rate, and burn-rate timelines to find the dominant contributors rather than guessing. Second, validate the SLO and the SLIs themselves before assuming the team is at fault. Confirm the target is realistic and meaningful, that the SLIs measure genuine user pain at the right boundary, and that the budget is not being burned by a misconfigured or overly strict indicator, sometimes the bar is wrong, not the team. Third, partner with the team blamelessly: share findings, prioritize the highest-impact fixes together, agree on an error-budget policy with explicit triggers, and decide the balance between reliability work and feature delivery. Bring in better testing, canaries, rollbacks, or chaos experiments as needed, and set up burn-rate alerts so problems surface earlier.

COMMON WRONG ANSWERS Blaming the development team without diagnosis. Immediately mandating a feature freeze before understanding the cause. Assuming the SLO is correct without validating it. Acting alone instead of partnering. Treating symptoms, restart loops, instead of root causes.

LIKELY FOLLOW-UPS How do you tell if the SLO itself is wrong. What does a blameless postmortem add. How do you prioritize the fixes. When is a freeze actually justified.

ONE CONCRETE EXAMPLE A team blows its budget three months running. You break down the burn and find 80 percent comes from one endpoint failing right after deploys, pointing to inadequate canarying. You also check the SLO and confirm 99.9 percent is reasonable for the service, so the bar is fine. You then sit with the team, agree to add canary deploys with automatic rollback and a burn-rate alert, and jointly prioritize that work for the next sprint, turning a recurring overspend into a concrete, owned fix.