How to Set SLOs and Error Budgets for a Team of Five

Reliability practice was written down by companies with hundreds of engineers, and most of what they publish assumes that scale. The arithmetic underneath it does not. A team of five can get most of the value from two numbers and one page of policy, and the value shows up in the argument you stop having every sprint about whether to ship the feature or fix the bug.

Pick the journey your customers would complain about

Start from what a customer does, not from your service diagram. Checkout, sign in, search, publish. One journey, at most two, and stop there. The SRE workbook recommends a small number of indicator types, five or fewer, covering the functionality that matters most to customers. For five people, one or two is the honest version of that.

Measure it as close to the customer as you reasonably can. A load balancer or edge log sees what the customer got. An internal service metric sees what one component believed it returned, and those two disagree in exactly the situations you care about.

Turn the journey into a ratio

Express the indicator as good events divided by valid events, times one hundred. Availability counts requests that did not fail. Latency counts requests served faster than a threshold you choose, so "99 percent of checkout requests complete in under 400 milliseconds" is a counting exercise rather than a percentile.

The threshold is a product decision and it belongs to whoever answers to customers, not to whoever owns the dashboard.

Do the minutes arithmetic before you pick a number

Choose the window first. Thirty days is easy for everyone to picture, and the workbook found a four week rolling window a good general purpose interval, which is the same arithmetic with 40,320 minutes in place of 43,200.

Thirty days is 30 times 24 times 60, which is 43,200 minutes. The error budget is what the objective leaves over.

Objective	Budget	Minutes per 30 days
99%	1%	43,200 x 0.01 = 432 (7 h 12 m)
99.5%	0.5%	43,200 x 0.005 = 216 (3 h 36 m)
99.9%	0.1%	43,200 x 0.001 = 43.2
99.95%	0.05%	43,200 x 0.0005 = 21.6
99.99%	0.01%	43,200 x 0.0001 = 4.32

Read the 99.9 percent row as a team of five rather than as a target. Forty three minutes for the whole month means a single incident that takes you fifty minutes to notice, diagnose and fix has spent the entire budget on its own. If nobody is awake between midnight and seven, and something can break at one in the morning, then 99.9 percent is not an objective, it is a wish.

That is the calculation most small teams skip, and it is the one that decides whether the rest of the exercise is real.

The same budget in requests

Time is the intuitive unit and requests are the useful one, because that is what you can count.

Suppose the checkout journey serves 3,000,000 valid requests in the window and the objective is 99.9 percent. The budget is 3,000,000 x 0.001, which is 3,000 failed requests. Halfway through the month you have had 1,200 failures, so you have spent 1,200 divided by 3,000, which is 40 percent of the budget with 50 percent of the window gone. You are slightly ahead, and nothing needs to change.

Burn rate is the same figure per unit of time. Divide the observed failure ratio by the budget ratio. A sustained 0.5 percent failure rate against a 99.9 percent objective is 0.005 divided by 0.001, a burn rate of 5, which empties a thirty day budget in 30 divided by 5, or 6 days. A burn rate of 1 lasts exactly the window, by definition.

That single number is what belongs on the wall. It answers the only question anyone actually asks, which is whether the current state of things is fine or not.

Do not set the target to the number you already hit

There is a strong pull toward measuring last month, rounding it, and calling it the objective. The workbook advises against choosing a target from current performance, since it commits you to whatever you happen to be doing now, including the parts that were luck.

Two failure modes bracket the right answer. A target you always miss teaches everyone to ignore it within two months. A target you have never once come close to missing is not constraining any decision, which means it is decoration. Aim for one you meet most months and occasionally sweat.

The policy is two rules and it fits on one page

An objective changes nothing until it decides something.

• Budget healthy. Ship. Deploy on Fridays if you want, take the risk, the numbers say you have room.
• Budget exhausted. Feature work on that journey stops, and the next cycle goes on reliability until the budget recovers.

Write it down and get whoever prioritises the roadmap to agree to it while nothing is on fire. Its whole value is that it was agreed in advance, so the conversation during the next bad week is a lookup rather than a negotiation between the person who wants the feature and the person who was up at 3am.

When the budget does run out, resist raising the objective so the problem disappears from the chart. Find what spent it, fix that with owned actions and dates, and only revisit the target if the evidence says it was wrong in the first place.

Review it monthly, in fifteen minutes

Once a month, look at three things. Where the budget ended, what spent the largest single piece of it, and whether the objective still matches what customers expect. Tighten it if you have not been near the edge in a quarter. Loosen it only with a reason you would be willing to tell a customer.

That is the whole practice at this size. Two numbers, one page, fifteen minutes a month, and an argument you stop having.

If you would rather have the first objectives defined and instrumented with you than derived from scratch, that is our SRE service, built on top of the monitoring and observability you already run. For the wider practice around it, including incident process and postmortems, see how to start doing SRE with SLOs and error budgets.