A template you can start from
Copy this and change the numbers. It is about one page, and it should stay that way. The reasoning behind each clause follows below.
ERROR BUDGET POLICY: Payments API
Owner: Payments engineering manager
Signed off by: Product lead, SRE lead, Engineering director
Reviewed: every 6 months, or after any policy exception
SERVICE LEVEL OBJECTIVES (rolling 28 days)
Availability: 99.95% of valid requests succeed
Latency: 99% of valid requests complete within 400 ms
Excluded: health checks, synthetic probes, requests rejected as invalid
WHAT HAPPENS AT EACH LEVEL
Budget remaining above 50%:
Normal releases. Reasonable risk-taking is welcome.
Budget remaining 25-50%:
Team reviews the top causes at the weekly meeting.
One reliability item is added to the next sprint.
Budget remaining 0-25%:
High-risk changes need SRE lead approval.
Reliability work takes priority over new features for at least one engineer.
Budget exhausted:
Release freeze except for reliability fixes and security patches.
Freeze lifts when the rolling budget is positive again,
or when the fix for the main cause has shipped and been checked.
A single incident uses more than 20% of the budget:
Postmortem required within 5 working days,
with at least one P1 action item.
EXCEPTIONS
Security fixes and legal or regulatory changes always ship.
Other exceptions: Engineering director, in writing, logged below.
ESCALATION
Disagreements go to the Engineering director.
Exception log: <link>Why write it in advance
Consider how this goes without a policy. The month's budget is gone. A product manager has a launch on Thursday, promised to a large customer. An SRE says it should wait. Both have good reasons, and the discussion gets settled by whoever has the most seniority or the loudest voice. Next month it happens again, with different people.
With a signed policy, nobody needs to win an argument. The product lead agreed months ago, with a clear head, what happens at zero. That's the entire point of the document. It's a decision made once, in calm conditions, and applied many times.
Working out the budget
Budget numbers should be specific enough that people can feel them. Take the template's availability SLO of 99.95% over 28 days.
Time-based view:
- Minutes in 28 days: 28 × 24 × 60 = 40,320
- Budget: 40,320 × 0.0005 = 20.16 minutes of full outage
Request-based view, if the service handles an example volume of 30 million valid requests in 28 days:
- Budget: 30,000,000 × 0.0005 = 15,000 failed requests
Use the request-based view for the policy, since it reflects partial failures. An outage at 3 a.m. and one at peak differ in user impact, and counting requests captures that. Then translate it into something tangible for the team. For example, "one bad deployment that fails 5% of requests for 30 minutes during peak uses about X% of the budget." If peak is 400 requests per second:
- Requests in those 30 minutes: 400 × 1,800 = 720,000
- Failures at 5%: 36,000
- Budget used: 36,000 / 15,000 = 240%
That one deployment would use the whole budget more than twice over. A number like that clarifies a conversation about canary releases far better than any abstract appeal to reliability. It may also show that the SLO is unrealistic for how the team ships today, which is worth knowing too.
Choosing the actions
The actions need to be things the team can actually do, and they should escalate gradually. A policy with only one trigger (a freeze at zero) means nothing happens for three weeks, and then everything stops.
Some useful measures, from light to heavy:
- Review the top budget consumers at the weekly team meeting.
- Move a reliability task to the top of the next sprint.
- Require a second reviewer for risky changes.
- Reduce the rollout speed, or increase the canary period.
- Assign an engineer to reliability work for the rest of the period.
- Freeze feature releases.
- Move on-call load back to the development team, if another team was carrying it.
A freeze is the most discussed option, and often the least useful on its own. Holding back changes can build up a pile of risky releases that all ship at once when the freeze lifts. What helps is changing what the team works on during the freeze. A frozen team with nothing different on its plate only gets a delay. The SRE Workbook's example policy also pairs the freeze with reliability work.
What about budget that goes unspent?
A team that always has plenty of budget left may have an SLO that is too loose, or it may be moving too cautiously. Either is worth a discussion. Spare budget gives you room for experiments, such as riskier migrations, chaos tests and faster rollouts. Don't use it as a reason to deliberately cause failures, though.
The hard cases to settle now
These cases always arrive. Decide them in the policy, not in the heat of the moment.
A dependency caused it. The database team's outage used your budget. Does the freeze still apply? There are two defensible positions. Counting it reflects what users experienced and can push you to add caches, fallbacks and timeouts. Excluding it reflects what your team controls. A common middle path is that the budget is spent all the same, but the freeze doesn't apply when the cause is entirely outside your control. Either way, the event should go to the dependency's owner as an input, and your SLO must not be stricter than what your dependencies make possible. If your database offers 99.9%, promising 99.99% on top of it without redundancy is not a real commitment.
A shared platform failure. Same question, one level down. If the Kubernetes cluster caused it, the platform team needs its own SLO and its own policy, or you will just keep having this discussion.
Planned maintenance. Does it count? From the user's perspective it's still unavailable. Many teams count it, because that encourages zero-downtime changes. If you exclude it, define it very narrowly, or the exclusion will grow.
An emergency feature. The company needs a change for a regulatory deadline. It ships. That's what the exception clause is for. Log it, so that a pattern is visible.
A wrong measurement. A bug in the SLI, or a bot flood, ate up the budget. Define who may correct the data and how it gets recorded. Corrections are legitimate, but quietly deleting bad days isn't.
A new service. During its first weeks, you don't have a reliable baseline. Run with the policy in report-only mode for one or two periods, then turn it on.
Getting it signed
The policy only works if those who feel its consequences have agreed to it.
- Start with data. Show the last 3 to 6 months of SLI performance. Would the budget have run out? How many times?
- Set the SLO from user needs and current reality. If you've been at 99.7% and declare 99.99%, the policy will freeze you permanently, and people will soon start ignoring it. Aim slightly above what you've achieved, and raise it as things improve.
- Talk to product first, not last. This is not an SRE document that gets imposed on them. Frame it as a way to know how fast they can safely go.
- Agree on a report-only period. Run it for a month, and see where it would have triggered.
- Get an executive to accept the escalation role. Without someone who can arbitrate, the first conflict will end the policy.
Keeping it alive
- Make the state visible. Put the budget remaining on a dashboard that product and engineering both look at. Include it in the weekly report. Scheduled reports do this with little effort.
- Use burn-rate alerts for the fast path. The policy covers the slow view, and burn-rate alerts cover the urgent one. They work with the same numbers.
- Attach causes to spending. Note which incident or change consumed each chunk. Lining up changes with budget drops shows which types of releases hurt you.
- Review it. Every six months, ask: did it trigger? Did we follow it? Was it useful? Change it if not.
- Track exceptions. If exceptions become routine, the policy is dead. Either the SLO is wrong or the organisation doesn't actually want this.
Traps
- Punishing teams. If the budget becomes a performance metric, people will start gaming the SLI or hiding incidents. It is a tool for choosing work, not for judging people.
- Too many SLOs. Two or three per service. A policy attached to fifteen indicators is impossible to follow.
- An SLO no user notices. If your SLO is met during outages that users complain about, fix the SLI before you do anything else.
- A rolling window surprise. With a rolling window, a bad day leaves the window exactly 28 days later, which can lift a freeze with nothing fixed. Include a clause about the fix.
- Copying someone's numbers. A budget, thresholds or freeze rule from a blog post, this one included, isn't tailored to you. Use them as a starting point.
Regulators in some sectors expect documented availability targets and change controls. If that applies to you, your compliance team may want this policy aligned with those documents. That's a matter for them to judge, and nothing here is legal advice.
How Wrentrix helps
Wrentrix tracks SLOs and error budgets with burn-rate alerts across 4 window pairs. Change correlation for Kubernetes and OpenShift lines up spec, ConfigMap, Secret and rollout-restart events against latency and error spikes, which helps with the question of what consumed the budget. Scheduled reports can put the state in front of people regularly. The policy itself, and the decision to honour it, remains yours.
Frequently asked questions
What is an error budget policy?
It's a short written agreement on what a team will do as it uses up the failure allowance of its SLOs. It sets out actions at different levels, such as shifting work to reliability or pausing risky releases. Its value lies in settling those decisions before the pressure arrives.
What happens when an error budget is exhausted?
That depends on your policy. Typically, feature releases pause, except for reliability and security fixes, and engineers move to reliability work until the budget recovers or the main cause is fixed. Some teams use softer measures, such as extra review for risky changes.
Should security patches ship during an error budget freeze?
Almost always yes, and the policy should say so explicitly. A freeze exists to reduce risk, and an unpatched vulnerability is a risk too. Ship them with normal care, and consider smaller, separate rollouts while reliability is under pressure.
Should an outage caused by a dependency count against my error budget?
Your users felt it, so most teams count it towards measurement. Whether it should also trigger a freeze is a separate decision that you should write into the policy. Repeated dependency failures are a signal to add fallbacks or to raise it with the owning team.
How often should I review an error budget policy?
Every six months is a common cadence, and also after any significant exception or a period when the policy clearly did not help. Check whether SLOs still reflect user needs, whether actions were followed and whether thresholds trigger too often or never. Keep the review short and record what changed.