Launching a risky feature with no error budget left

WHAT THIS TESTS This evaluates whether you treat the error budget policy as a framework for negotiation and shared accountability rather than a rigid gate, and whether you can marshal evidence.

A GOOD ANSWER COVERS First gather the facts: what actually consumed the budget this quarter, whether it was one large incident or steady erosion, the current burn rate, and how much time remains in the window before reset. Distinguish whether the budget was spent on incidents the team has already fixed versus ongoing instability, because a single resolved outage is very different from a service still degrading. Quantify the proposed feature's risk: its blast radius, how many users or what fraction of traffic it touches, whether it can be isolated, and how fast and cleanly it can be rolled back. Then make the technical argument: present the SLO and user impact data, and rather than a flat yes or no, propose mitigations that shrink the risk, such as launching behind a feature flag, starting with a tiny canary or one percent rollout, gating expansion on live SLI data, and ensuring an instant rollback path. This turns the conversation into a shared decision with the product manager and leadership.

COMMON WRONG ANSWERS Issuing an absolute veto purely because the budget is gone, which makes SRE an obstacle and ignores business context. The opposite error is rubber-stamping the launch despite the exhausted budget and an unstable service, undermining the whole point of the policy.

LIKELY FOLLOW-UPS Who holds final authority when SRE and product disagree? How does burn-rate alerting inform this? What does the documented error budget policy say about exceptions? How would a canary tell you to halt?

ONE CONCRETE EXAMPLE The budget was exhausted by a single network incident three weeks ago that is now fully resolved, and the service has been stable since. You show that the burn has flatlined and only ten days remain in the window. You propose shipping the feature behind a flag to one percent of traffic, watching the error rate and latency SLIs for forty-eight hours, expanding only if they stay clean, and keeping a one-click kill switch. Armed with this, the team and PM agree to a controlled launch instead of a blanket freeze, a decision grounded in data rather than dogma.