Error Budget Explained. How to Calculate It and When to Stop Shipping

An error budget is 100% minus your SLO, the amount of unreliability you have agreed in advance that you can afford. At a 99.9% target that is 0.1% of the window, roughly 43 minutes of downtime a month. That number tells you when to ship and when to stop.

Your team ships. Incidents pile up. Someone suggests slowing down to fix the platform, and the room splits into people who think it is bad enough already and people who think it is not. Nobody has a number, so the loudest opinion wins.

An error budget lets you balance reliability against the pace of feature development without holding that argument every month. Below you will find the formula, the thresholds that show how fast you are spending, the policy that settles the argument in advance, and a stripped-down version for teams with no SRE function.

What is an error budget and how does it relate to your service level objective?

An error budget is the amount of unreliability a service can tolerate in a given period. It is 100% minus your SLO, so a 99.9% target leaves 0.1%, roughly 43 minutes a month.

Put plainly, the error budget represents how much unreliability your product can carry before something has to change. You are not guessing what users will tolerate. You are doing subtraction on a target you chose. Set the service level objective at 99.9% and the budget is 0.1% of whatever window you measure. Nothing exists until the target does, and that is why service level objectives (SLOs) and error budgets get discussed as one thing rather than two.

The idea grew out of site reliability engineering (SRE), and it has almost nothing to do with monitoring tools. Inside that tradition the error budget forms a control mechanism. It pulls attention toward system reliability at the moment the numbers say attention is needed, not when somebody finally loses patience. Both sides accept the figure while nothing is on fire. After that, slowing down stops being a matter of taste. It becomes a question of how much allowance is left.

That is what makes the figure worth putting on a wall. Your development team, the product managers who own the roadmap, and whichever SRE teams or tech teams carry the pager all read one number and reach the same conclusion. A shared figure turns two competing instincts into a single set of informed decisions about where the next sprint goes. Nobody has to win an argument about whether users are unhappy, because the target already encodes the user expectations it was built around. Service reliability stops being a value everyone claims to hold. It becomes a quantity somebody is spending.

Understanding error budgets means accepting one more thing. You cannot lift a target off one service and drop it on another. Acceptable downtime for an internal reporting tool and acceptable downtime for a checkout path are different quantities, even though both are web applications. The allowable downtime you can defend depends on what a service does at its worst moment, not on average. A learning platform running scheduled assessments needs a stricter number than a dashboard nobody opens on a Sunday. Anyone who has weighed that difference on a live product will recognise the trade-offs in how we built an online learning platform, and it is the same reason engineering for growing EdTech scaleups rarely starts from a borrowed uptime figure.

How do you calculate an error budget?

Subtract your SLO from 100%, then multiply what is left by the length of your measurement window or by the number of requests you expect. A 99.9% target leaves 0.1%. Across a month that is about 43 minutes. Across a million requests it is a thousand failures.

Every calculation starts from that subtraction. Teams running several services end up with several SLO error budgets, one per target, and they differ only in the unit somebody picked. One detail decides whether your table is right, and it is the length of a month. The figures below treat a month as one twelfth of a year, which is how reliability targets are normally converted. Measure against a strict 30-day month and every monthly figure shrinks slightly. Pick one convention, write it into your policy, and stop converting it again.

Window length moves the budget as much as the target does. A 1% budget across a 28-day window is 6.72 hours of failure. The same 1% across a year is more than 87 hours. Shorten the window and the budget tightens without anyone touching the SLO.

There's a catch. Count your budget in minutes and count it in failed requests, and you describe the same target while behaving nothing alike during an incident. Minutes hide a service that answers every request slowly or wrongly while technically staying up. Failed requests hide how long one outage lasted. Here is where error rates stop being a dashboard curiosity and become the thing you budget against.

Instrumenting a request-based budget is easier on a backend you own end to end. That argues for keeping the critical request path inside your own Node.js development services instead of behind infrastructure you cannot measure. Minutes also behave badly wherever a wrong answer costs more than no answer, a common pattern in custom healthcare software.

How do error budgets work once error budget tracking is in place?

Error budgets work as a decision tool, not as a report. Whichever unit you picked, the arithmetic answers one question. How much failure can you accept before the target breaks?

That figure becomes one of the few key metrics a small team can act on without a platform team behind it. Error budget tracking buried in somebody's spreadsheet does not minimize downtime. It records it.

Put the remaining error budget in front of the people making release decisions. One number, one place, and everybody trusts it. Error budget tracking that reaches your development team once a month is a scorecard. Tracking that reaches them on the day the burn rate spikes is a control. Same arithmetic, different mechanism.

Try our developers.
Free for 2 weeks.

No risk. Just results. Get a feel for our process, speed, and quality — work with our developers for a trial sprint and see why global companies choose Selleo.

Test our team

Share this offer

How do a service level indicator, a service level objective and a service level agreement shape your error budget?

The SLI is what you measure. The SLO is the internal target you set for it. The SLA is the external promise with penalties attached. Your error budget comes from the SLO, never from the SLA.

That ordering is not academic. Set an SLA at 98% and an SLO at 99%, and your budget is the 1% the SLO leaves you. It runs out while you still have a full percentage point of contractual room. The gap is the warning. You find out you are in trouble before a customer can invoice you for it.

Read the stack from the outside in. Your service level agreement holds the number promised to the customer. Your service level objective holds the stricter number you keep for yourself. A service provider that sets both at the same value has no early warning left, only a penalty. Meeting contractual promises is the floor, and the SLO exists to keep you well above it. Contractual promises are also why SLOs and error budgets get taken seriously at all in companies that sell uptime.

You will find definitions that tie the error budget to the contract and to what a customer can penalise. At first glance, this looks fine. It isn't. A budget derived from the SLA runs out at exactly the moment the penalty starts, so the warning gap disappears. Your target has to be stricter than your promise for any of this to do work.

None of these figures measure customer satisfaction directly. They are proxies. A good SLO is the proxy that moves at the same time user dissatisfaction does, and that is harder to build than a target copied off a competitor's status page. Where the promise carries money, as in fintech software development, the gap matters most. Where there is no contract at all, the SLO is the only number you have.

How fast are you burning it? Error budget burn rate explained

Burn rate is your current error rate divided by the error rate your SLO allows. At a burn rate of 1 the budget lasts exactly to the end of the window. Above 1 it runs out early.

Waiting for the balance to hit zero is waiting too long. A burn rate of 3 empties a monthly budget in ten days, so a team watching only the remaining budget finds out on day ten that it lost a week. Burn rate turns error budget consumption from a monthly report into a live signal about system health.

Two burn rate thresholds do most of the work. A warning fires at 25% of the budget remaining or a burn rate above 2x. A critical alert fires at 10% remaining or above 5x on short windows. Every one of those numbers is meaningless without the window it applies to. A 5x burn rate across five minutes is a spike. A 5x burn rate across a week is a broken service.

Real time alerts on burn rate separate error budget depletion you can still respond to from error budget depletion you discover in a retrospective. Your alert does not have to be clever. It has to fire while there is still budget left to protect. Two thresholds and one channel beat a dashboard nobody has open.

Set burn rate thresholds too tight and you buy alert fatigue instead of information. Two thresholds cover most services, and every extra one costs attention you will need during a real incident. Page an on-call engineer three times a week and you teach them to close the page without reading it. That leaves you with worse visibility into system health than no alerting at all.

What happens when the error budget runs out?

Feature releases stop until the service is back inside its SLO. P0 issues and security fixes still ship, conditional on root cause analysis, and when product and engineering disagree the decision escalates to the CTO.

That last clause is the part nobody talks about. Your CTO settles disputes about freezing releases, and the mechanism gets written down before anyone needs it. A freeze negotiated during an outage is not a mechanism. It is the same argument with worse timing.

Which feature releases stop and which still ship?

What actually stops is new features. Feature development pauses while operations tasks and reliability work move to the front of the queue. It resumes once the service is back inside its target.

A system rollback, a config revert and a hotfix are none of them feature releases, so none of them wait. Write that distinction down, because during an incident somebody will argue about it. Skip this step and you end up deciding case by case, the exact thing your error budget policy was meant to remove. One line covers it. Feature releases wait, repairs do not.

Seven rules cover almost every situation you will hit. The budget is gone but the ticket is a P0 or a security fix, so you ship anyway once the root cause is understood. Something outside the team's control burned the budget, so you do not freeze automatically. A single incident ate more than 20% of the budget, so the postmortem stops being optional. The burn rate crossed 3x, so you freeze now instead of waiting for the balance to reach zero. Product and engineering cannot agree, so the CTO decides. The budget was never spent at all, so the target is too loose and needs tightening. The budget empties every window and no user has complained, so your indicator measures the wrong thing and the target is fine.

Integrating error budgets into how the team already works matters more than the wording of any document. A budget sitting beside incident response instead of inside it gets remembered after the incident rather than during it, which is exactly backwards. Freezing exists to prevent further customer impact while the cause is still being understood. Recording customer impact afterwards is a different job.

Those last two rules point somewhere uncomfortable, and there is a whole section on that further down.

What belongs in an error budget policy and how does it fit incident response?

A policy names what stops, what still ships, who can grant an exception, and who settles a disagreement. Half a page is enough. The canonical example measures the budget across four weeks, not a calendar month.

Five things have to be in there. What exactly stops when the budget is gone, and what still goes out regardless. Who can grant an exception and under what condition. Where a disagreement goes when the exception is refused. The window the budget is counted across. The share of the budget a single incident has to consume before a postmortem becomes mandatory, set at 20% in the canonical example.

Keep the policy inside incident response, not in a document sitting next to it. The moment it matters is the moment somebody is already paged. Reaction can scale with the window too. A one-day budget running out triggers an automated alert. A seven-day budget escalates to the development team. Thirty days blocks releases, and ninety days goes to the board. That ladder assumes four organisational levels exist, and most teams reading this have two.

Larger organisations split the ladder between operations teams and product, which turns the policy into cross functional collaboration rather than an engineering document. A two-level version does the same job, as long as both levels agreed to it in writing. Freezing only holds when everyone touching the codebase knew the rule in advance, and that is harder across dedicated development teams than inside one co-located group.

Should you use a rolling window, a calendar month or only business hours?

A rolling window rewards fixing things fast, because old violations age out of the measurement and the budget recovers. A calendar window resets at a fixed moment. Simpler to report, less forgiving.

No standard exists here. The canonical policy counts four weeks, established practice elsewhere counts a calendar month, and 28-day windows are common too. Treat the window as a decision you make and document, not a constant you inherit. It is real money in budget terms, since a 1% budget is 6.72 hours across 28 days.

Some teams count only business hours, on the grounds that a failure at three in the morning reaches fewer users. That shrinks the allowed downtime and excludes the hours when nobody is watching. Two separate effects, and both need a decision. A calendar window also has one specific failure mode. An outage on the 28th costs the team the same budget as an outage on the 3rd, and leaves no time to earn any of it back before the reset.

Does a planned maintenance window spend the error budget?

Planned maintenance spends the budget as surely as an incident does. Scheduling a maintenance window is a decision to release part of the budget on purpose, and that is reasonable as long as somebody counts it.

The mistake is excluding every maintenance window from the measurement because it was announced. A user who cannot log in does not care whether the outage was on a calendar. An indicator that ignores announced downtime drifts away from what people actually experience. Count the window first, then decide whether the target can carry it.

How do you run error budgets without an SRE team?

Start with one indicator, one target, one window and a spreadsheet. A single SLO on the one request path your users care about gives you a working error budget in a week, with no platform and no SRE function.

Implementing error budgets the way the standard playbook describes assumes things a twelve-person team does not have. Composite SLOs need weights agreed with the business. Burn rate alerting needs request-level telemetry. A four-level escalation ladder needs four levels. All of it pays off later. None of it pays off before you have one stable single-service SLO to build on.

Five steps get you there.

1. Pick the one user-facing request path that matters most, and one indicator for it.
2. Set a target you can defend, then check what budget it leaves you in minutes or in failed requests.
3. Choose a window and write it down. Four weeks and thirty days both work, and mixing them does not.
4. Write half a page of policy covering what stops, what still ships and who decides.
5. Review after the first full window and adjust the target, not the policy.

Reduction is the point. Two escalation levels instead of four, one alert threshold instead of two, and no composite SLO until single-service targets have survived a few windows. Composite SLOs earn their keep on a whole user journey. They are also the fastest way to spend three weeks arguing about weights while nothing gets measured.

How do you set realistic SLOs when implementing error budgets?

You are not building a perfect model. You are enabling teams to make one decision they could not make last quarter. Most teams that use error budgets effectively started with a slightly wrong target and corrected it after one window.

Realistic SLOs come from history, not ambition. Look at what the service delivered over the last three months and set the first target just inside that range. Setting unrealistic SLOs on day one kills the mechanism, because a target nobody believes gets quietly ignored. Engineering teams tighten reliability targets once the mechanism has proved it works, not before. Treat the first three windows as continuous improvement on the target rather than a verdict on the team.

Most people miss this part. Step 5 points at the target, not at the code. A budget that was never touched means the target is too loose to trigger anything. A budget that vanished in four days means either the service is worse than anyone admitted or the indicator is wrong. Adjust the target after the first window and leave the policy alone, because the policy is the only part that stops being credible if you keep editing it.

Reliability goals nobody can trace to a number are wishes. A budget converts a reliability goal into a quantity of failure you are allowed to spend, and that puts reliability investments on the same footing as feature work. Without it, reliability competes against the roadmap on feeling alone, and feeling loses.

Most small teams cannot free a person to own reliability full time, so the first SLO gets set alongside staff augmentation services rather than after a hire that is six months away. Teams wanting the budget tracked automatically reach that point once their DevOps and cloud services emit request metrics they trust. The reduced playbook exists because the full one assumes a level of specialisation that arrives much later when scaling engineering teams.

How does an error budget change the conversation with your board?

An error budget gives you one number to bring to the board instead of an opinion. You stop arguing about whether the product is stable enough and start reporting how much allowance is left.

Let's be honest for a second. Without a budget, asking for reliability work sounds like engineering asking for time, and the answer depends on how convincing you were that week. With a budget, a freeze executes a rule that was signed off before the incident happened, and the same people now asking why the roadmap slipped are the ones who agreed the target.

Reporting gets short. Twenty-five percent left with two weeks to go means releases continue and someone is watching. Ten percent left means releases stop. Neither sentence requires the board to hold an opinion about your architecture. An error budget belongs in the same conversation as software delivery performance, because both replace a story about how the team feels with a figure the business can read.

Product managers get the same benefit from the other direction. While the remaining budget looks healthy they can push new features without asking permission, and once it is spent, the conversation about balancing innovation against reliability has already happened. Informed decisions look like this when both sides hold the same number.

One more effect is worth naming. When the budget is the unit of accounting, a postmortem covers how the allowance got spent instead of who spent it, and that changes who is willing to report a problem early.

The same number travels outward too. A service level objective stated in plain figures is something an account manager can quote without calling you, and it keeps the promise you make to customers tied to the service level agreement you actually signed. Customer satisfaction is not a metric you can budget against directly, but a target built around real user expectations is the closest usable proxy. That is what makes informed decisions possible one level above engineering, where nobody wants to read a dashboard.

Where do error budgets go wrong?

Two failures dominate. A target built around what was easy to measure rather than what users feel, and a budget that gets tracked but carries no agreed consequence. A budget you never spend means the target is too loose. A budget you always blow while nobody complains means your indicator measures the wrong thing.

Most of the damage comes from a short list of patterns.

• an SLO built around the metric that was easiest to instrument, not around the request path users depend on,
• a budget used to hold individuals accountable instead of to make a decision,
• a policy written during the outage it was meant to govern,
• a budget that is measured and reported but carries no consequence anyone acts on,
• alert thresholds tight enough to cause alert fatigue, so the team stops reading them,
• a target so loose that the budget is never spent and the mechanism never fires.

The first one is a measurement problem before it is a reliability problem. An indicator chosen because it already sat in a dashboard will look healthy through outages that users notice, and that is why software quality assurance services and SLO design tend to arrive together instead of in sequence. Picking a target the service has already survived for a full window beats picking one that sounds ambitious.

The fourth one is the quiet failure. A budget calculated every month, reported every month and never acted on behaves exactly like what is technical debt on the reliability side. Tracked, acknowledged, never paid down. The consequence is the mechanism. Without it you have a metric.

An error budget policy that exists on paper and nowhere else fails the same way. A policy nobody has read during an incident is not a policy. It is a document. Ask two engineers what happens when the budget runs out. Two different answers mean the mechanism does not exist yet, whatever the wiki says.

Two more failures deserve naming, because from the inside they look like success. A team reporting reliability improvements every quarter while user dissatisfaction climbs is measuring the wrong thing. A service provider that never breaches its own target and still loses customers has an indicator problem, not a reliability problem. Maintaining reliability is not the same as maintaining a green dashboard. Overall reliability is what users experience. System reliability is what your instrumentation reports. Reliability issues that never show up in the budget are the expensive kind, and the distance between those two numbers is where wasted reliability work lives.

External dependencies deserve honesty here, because established practice has no good answer. A third-party service can burn your budget while your team has no lever to pull. The canonical policy covers it with one principle. A budget consumed by circumstances outside the team's control does not automatically trigger a freeze. That protects the team from being punished for something it cannot fix, and it does nothing to fix it.