Your team's error budget for checkout-worker just dropped from 80% remaining to 20% in six hours — walk through how you'd identify which dependency or deploy caused the burn and decide whether to trigger a feature freeze.

A sudden 60-percentage-point budget drop in six hours is like a household's bank balance dropping sharply in a single afternoon — the sensible first move isn't reviewing every transaction from the past month, it's pulling up exactly what happened in that afternoon's window, because a change that dramatic almost never comes from gradual, ordinary spending, it comes from one identifiable event: a large purchase, a fraud charge, a mistaken transfer. Error budgets behave the same way — organic, gradual drift rarely produces a cliff this steep this fast, so the investigation should start by asking 'what changed in this exact six-hour window,' not by re-examining broad service health from scratch.

This correlation-first approach exists because budget burn, by construction, is just an aggregate of a huge number of individual failed or slow requests, and that aggregate number alone tells you nothing about causation — it's a symptom-level metric, not a diagnostic one. The entire reason to track deploy history, dependency health, and configuration changes alongside SLO dashboards is so that when the aggregate number moves sharply, you have an immediate, pre-correlated list of candidate causes to check, rather than starting a root-cause investigation completely from scratch under time pressure.

Step by step: first, pull the deploy timeline for checkout-worker itself and every service it directly depends on, and overlay it against the exact start time of the burn — if a deploy landed in or near that six-hour window, that's the leading suspect and should be checked first, since deploys are statistically the single most common trigger of sudden reliability regressions. Second, if no relevant deploy lines up, check the health and latency of checkout-worker's direct dependencies (databases, downstream APIs, message queues) over that same window, since an upstream degradation can burn a *downstream* service's budget even when the downstream service's own code never changed at all. Third, break down the failing requests themselves by endpoint and status code — a burn concentrated on one specific endpoint or a single error code (say, every failure is a 503 from one particular downstream call) narrows the search dramatically faster than treating the whole service as uniformly degraded. Fourth, check whether the burn is still actively ongoing at the moment of investigation or whether it was a discrete, already-resolved incident (a bad deploy that was already rolled back, a transient dependency blip that's already recovered) — this distinction is the actual determinant of what happens next.

At the organizational level, this is exactly where the pre-agreed freeze policy gets tested for real: if the burn is over and resolved, the appropriate response is a postmortem and, if the remaining budget for the window is now thin, heightened caution on further risky changes — but a full feature freeze over an already-resolved incident is usually disproportionate. If the burn is still active and ongoing, that's precisely the scenario the freeze policy was designed for: continuing to ship new changes into an environment that's already actively burning budget compounds risk on top of an unresolved problem, and the freeze exists to stop adding new variables until the existing one is under control.

The gotcha: teams that treat 'trigger the freeze' as an automatic, mechanical response the instant budget drops below a threshold — without first distinguishing an already-resolved historical burn from an actively ongoing one — end up freezing feature work over incidents that are already fixed, which trains the organization to see the freeze policy as arbitrary and punitive rather than a genuinely protective mechanism, and erodes the willingness of product stakeholders to honor the policy the next time it's actually needed for a real, ongoing problem.