Error Budget

Every team that runs a service carries two forces pulling in opposite directions. One wants to ship faster, the other wants the service to stay up. Every deployment raises the odds of an outage, so the two are competing over the same resource.

The problem was that the competition had no scoring rule. Mia proposes shipping the payments screen on a Friday, Theo says it's risky, and from there the louder voice wins. If there was an outage last month, Theo wins. If things have been quiet, Mia wins. The same risk gets a different answer depending on what happened the week before, and both of them walk away thinking the other one is arguing from feel.

Setting a target of zero failures looks like a way out, and it's worse. Driving failure to zero means not deploying at all, and a product that isn't deployed doesn't grow. Removing the last one percent of risk costs more than removing the first ninety did.

An error budget replaces the argument with a rule rather than ending it. The amount of failure the team is allowed to spend is written down in advance: while it lasts, you ship; when it runs out, you stop. What used to be settled in a meeting is now settled by a balance.

Subtract the target from 100 percent, then multiply that share by the total requests or total time in the period. Four steps.

1. Choose what to measure. The value that actually measures service quality is called a service level indicator (SLI). Pagedeck uses the success rate of document save requests, because whether a document really saved when someone pressed the button is the sorest spot in this product.
2. Set the target. The line a team commits to holding that value at is its service level objective (SLO). Say it's a 99.9 percent save success rate.
3. Whatever is left over is the budget. 100 minus 99.9 leaves 0.1 percent.
4. Multiply by the total. At 30 million save requests a month, 0.1 percent is 30,000. Those 30,000 are the failures this month is allowed.

The balance falls as it gets spent and refills when the month rolls over. If a bad deployment breaks saving for 40 minutes and 12,000 requests fail during it, that single incident spent 40 percent of the month, and the remaining three weeks have to fit inside 18,000.

Measuring in time works the same way. Over a month, 99.9 percent allows 43 minutes of downtime. Move one digit to 99.99 percent and it drops to four minutes. Each extra nine cuts the allowance to a tenth of what it was, and that is the part of the arithmetic people miss most often. It's why a team used to reading uptime can write a more ambitious number without thinking and then burn the whole budget in the first month.

A large remaining balance is not a good state. This budget is an allocation to spend, not savings to protect. If 90 percent of it is still there at the end of every month, one of two things is true: the target was written looser than the team's real capability, or the team is holding back work it could have shipped. The second case means shipping one improvement in the time a competitor ships three.

Aim to end the month having spent somewhere between 60 and 80 percent. That says the service held its target and the allowance wasn't left idle. Three months at 20 percent is a sign it's time to raise the target from 99.9 to 99.95. Three months of spending it all in week one says the target isn't reachable with the current architecture.

Deciding the rule for an empty budget in advance is half of what makes this metric work. At Pagedeck, hitting zero stops feature deployments and leaves only stabilization work. The rule runs the other way too: when the balance is healthy, Theo doesn't object to risky-looking experiments, because there is still a share of failure available to spend.

One more thing worth watching is the shape of the burn. A small, even decline every day means the service simply performs at that level, which points back at the target itself. A flat line that drops sharply only on deployment days points at the deployment process instead, and in that case it is worth reading alongside the change failure rate.

"We've burned 70 percent of the error budget this month. Let's push the Friday deploy to next week."

What's left isn't enough to absorb a weekend problem.

"More than 80 percent of the budget is still there — why are we holding this experiment?"

Safety isn't a sufficient reason to delay when the numbers say otherwise.

"This failure fits inside the budget, so nobody needs to be woken up."

It isn't threatening the target, so it can wait until morning.

At Pagedeck the Monday operations meeting opens on this balance. Theo reads out what's left and where last week went, and any sharp drop gets matched against the deployments from that day. Mia uses the number to decide what ships that week. In a week where the balance has fallen below half, items that change large parts of the interface get pushed back and the lighter ones go first.

The service level agreement (SLA) written into enterprise contracts sits one notch looser than this. Promising customers 99.5 percent while holding the team to 99.9 percent leaves room to react between the moment the budget empties and the moment refunds are owed.

The most common misreading is treating an error budget as permission to have outages. It does write down an allowed quantity of failure, so the reading is understandable. But what the number permits is a calculated risk, not a failure. An outage caused by no preparation at all spends budget, and so does a deployment that was rolled back within five minutes because someone was watching for it. Measuring both on the same scale pushes teams toward noticing fast and reverting fast. Miss that and the budget becomes an excuse for unprepared deploys, and the balance hits zero in week three with most of the month left.

The other one is treating a leftover balance as an achievement. The instinct that unspent money is money saved carries straight over. In practice an unspent budget doesn't roll into next month — it simply disappears. Having leftovers means improvements that could have shipped didn't. Once that belief sets in, protecting the balance becomes the goal, and six months later the service is extremely stable and the product is identical to last year's.