Error Budgets in DevOps Transformations: Your Questions Answered

Ask ten CTOs mid-transformation what their reliability target is and nine will say “as high as possible.” That answer is why their release calendars keep collapsing. Any serious modernisation programme eventually collides with one blunt question: how much failure will the business tolerate while we change everything underneath it? Error budgets in a DevOps transformation pin that question to an agreed figure rather than a mood, and in our consulting work they routinely turn out to be the single highest-leverage artefact an engagement produces. Below are the questions clients actually ask us about them, answered without the fluff.

What exactly is an error budget, in one paragraph?

You pick a measurable objective for a service — for example, 99.5 percent of checkout requests succeed within two seconds, measured monthly. The distance between that objective and 100 percent is your allowance for failure: the error budget. While the allowance holds, teams ship changes freely. When it’s spent, releases to that service stop and the effort goes into stability until the number recovers. That’s it. No dashboard worship, no committee. A target, an allowance, and a pre-agreed rule about what happens at zero.

Why does this matter more during a transformation than in steady state?

Because transformation is when change volume spikes and nobody knows the new system’s failure modes yet. Containerising workloads, splitting a monolith, re-platforming CI — every one of these raises short-term risk in exchange for long-term speed. Without an explicit allowance, the first production wobble triggers an executive overreaction: change freezes, steering-committee theatre, momentum gone. With a budget, the wobble is either affordable (keep going) or it isn’t (pause, stabilise, resume). The transformation keeps its credibility precisely because its risk is visibly governed. We’d go as far as saying the budget is a precondition for the agility outcomes described in a strategic look at how consulting-led DevOps adoption unlocks enterprise agility — speed without a stated tolerance isn’t agility, it’s gambling.

Who should set the targets — engineering or the business?

Both, and in that order of drafting but the reverse order of authority. Engineering proposes what’s measurable and achievable; the business decides what’s tolerable, because they own the consequences. A payments flow and an internal reporting tool should never share a target. In practice we run a half-day workshop per critical service: product names the user expectation, engineering names the current reality, and the gap between those two numbers becomes the roadmap. If the business refuses to accept anything below 100 percent, that’s not a workshop failure — it’s the moment to explain, with their own incident history on the table, that they’ve been running below 100 percent all along without deciding to.

Isn’t this just SLAs with extra steps?

No. An SLA is a contract with penalties, pointed outward at customers. The internal objective behind it should always be stricter, so you breach your own threshold — and react — long before you breach the contract. The budget is the reaction mechanism: it converts “we’re trending badly” into an automatic operational decision rather than an argument. Firms that formalise this distinction tend to pull it from the reliability engineering canon; SRESchool’s consulting and training practice covers SLO and SLA strategy, incident management and error-budget operations as a connected discipline rather than isolated tricks, which is the right way to absorb it.

What happens politically when the budget runs out?

This is the real question, and the honest answer is: whatever you agreed beforehand, which is why you agree it beforehand. The policy needs three clauses signed by someone senior enough to make it stick. One: which work stops (feature releases to the affected service). Two: which work continues (security patches, the transformation’s own stabilising moves). Three: who can override, and in writing. The override clause matters — there will be a quarter-end exception eventually — but making overrides explicit and logged keeps them rare. Teams fold the same pre-agreement thinking into secure delivery too; the gating logic resembles what a practical guide to wiring security into delivery pipelines recommends for security checkpoints: decide the rule when calm, enforce it when not.

Can we run error budgets while half our estate is still legacy?

Yes, and you should. Legacy systems benefit disproportionately because their failure tolerance has usually never been stated — it lives in the folklore of whoever has been operating them longest. Start with a measured baseline: instrument the service, observe four to six weeks, and set the first objective slightly below demonstrated performance. That sounds unambitious; it’s deliberate. A first target you can meet builds the habit. Tighten later, service by service, as the modernisation replaces the shakiest components. The sequencing belongs in the engagement plan from day one, alongside assessment and enablement phases — the same structural discipline laid out in our playbook for structuring an engagement, opening assessment to final enablement.

What should we measure first if we’re starting from nothing?

Pick one revenue-adjacent user journey and give it two indicators: availability (requests that succeed) and latency (requests that succeed fast enough to count). Resist the urge to launch with fifteen metrics; two indicators on one journey, reviewed weekly, beats a measurement programme nobody reads. Expand only when the first budget has survived one full breach-and-recovery cycle, because that cycle is where the organisation actually learns the method.

How do we build internal capability instead of renting it forever?

Three moves, in parallel. First, embed the policy in writing — a two-page document outlives any consultant. Second, make one named engineer per critical service the budget owner, with the review on their calendar, not a shared one. Third, train deliberately: reliability engineering has a recognised certification ladder now, and for transformation teams the architect-level track (CSRA) suits the platform leads who must design services that can honour a target in the first place. Corporate formats exist with private batches and a syllabus tuned to your stack, delivered on-site or virtually, which beats sending individuals off one at a time when a whole platform group needs the same vocabulary in the same quarter.

Where does this usually go wrong?

We see three recurring failure patterns, each avoidable. Budgets set but never enforced — the number exists, breaches change nothing, cynicism follows; prevention is the signed policy. Targets copied from a blog instead of negotiated — the tolerance fits someone else’s business; prevention is the workshop. And budget theatre — teams gaming the measurement window or reclassifying incidents to protect the number; prevention is measuring from the user’s side, not the infrastructure’s, so there’s nowhere to hide. If you recognise your organisation in any of these, the fix is cheaper than you think, because the machinery is already half-built; it just needs teeth.

How long until this pays for itself?

Faster than most transformation artefacts, because the payoff arrives at the first incident rather than the first anniversary. The moment a production problem is classified as “within budget” and the release train keeps moving — where last quarter the same problem would have frozen delivery for a fortnight while committees met — you have recovered more engineering time than the workshops cost. The second payoff lands at the first genuine breach, when stabilisation work gets prioritised without a single escalation email, because the policy already answered the question. Expect both moments inside the first ninety days if you actually enforce the rule. If neither has happened in six months, the budget exists on paper only, and you should revisit the political clauses before adding any more measurement.

One caution on expectations: the first few weeks often feel slower, because conversations that used to be skipped are now happening. That friction is the method working — those were decisions being made by default before, and defaults during a transformation are rarely the decisions you’d choose.

Bottom line

A transformation without an explicit failure tolerance will set one implicitly — usually at the worst moment, by a frightened executive, at a value of zero. Error budgets are how you make that decision on purpose, in daylight, with numbers the business chose. Set one target on one journey this month, write the exhaustion policy on a single page, and enforce it once. Everything else about the practice grows from that first enforced breach.

Kabir Malhotra