A familiar scene in a growing company: a bad week of incidents, a tense meeting, a decision to "focus on stability" for a sprint, and then feature pressure creeps back until the next bad week. Nobody is wrong. Product wants to ship, engineering wants to stop firefighting, and there is no shared definition of "reliable enough" to settle the question.
Error budgets were designed for exactly this. The original Google SRE book frames reliability as a target to be chosen, not maximised, because every extra nine costs something5. Once the target is agreed, the gap between it and perfection is a budget the team is allowed to spend.
Start smaller than you think
Small teams fail at SLOs by trying to cover everything. Two or three objectives on the user journeys that matter most is enough to start:
- Availability of the core API or page: the proportion of valid requests that succeed.
- Latency for the same journey: the proportion of requests faster than a threshold users would notice.
- Freshness or correctness for data products: the proportion of runs completed on time.
Measure at the edge closest to users, such as the load balancer or gateway, and set the first targets from what you achieved over the last month. The Workbook recommends writing the SLOs down with owners, approvers and review dates, and its example document gives each objective its own budget of 100% minus the target14.
Write the policy before you need it
The SLO is a number; the policy is what makes it matter. The Workbook says a policy should state the actions taken when the budget is exhausted and a clear escalation path for disagreements1. Its example policy is a useful template2:
| Trigger | Example action |
|---|---|
| Budget exhausted over the preceding four weeks | Halt changes and releases other than P0 issues and security fixes until back within SLO |
| A single incident consumes over 20% of the four-week budget | Postmortem with at least one P0 action item |
| One class of outage consumes over 20% of the quarterly budget | A P0 item in next quarter's plan |
| Budget spent by causes outside the team's control | Listed exceptions, such as company-wide network problems |
For a small company, a softer version often works better: rather than halting all releases, the next sprint's capacity goes to reliability work until the budget recovers. What matters is that product and engineering leadership sign it together, before the next bad week.
The error budget's real value is political, not technical. It replaces an argument about feelings with a rule both sides agreed when they were calm.
Alert on burn rate, not on errors
Paging on every error spike burns out small on-call rotations fast. The Workbook's guidance is to alert on how quickly the budget is being consumed, combining multiple time windows and burn rates so that fast, severe problems page someone while slow leaks become tickets3. With two or three SLOs, that typically means a handful of alerts in total, each of which genuinely matters.
The telemetry comes from the same pipeline as everything else; the OpenTelemetry Collector patterns make it straightforward to compute SLIs centrally.
What changes once it's running
- Prioritisation gets easier. Budget remaining means ship; budget gone means fix. The weekly debate shrinks to a glance at a dashboard.
- Postmortems get sharper. Budget consumed per incident is a better severity measure than whoever shouted loudest, and pairs well with the practices in AI incident postmortems.
- Delivery metrics gain context. DORA metrics say how fast you ship; error budgets say whether the speed is affordable.
- Customer conversations improve. An SLO you actually meet is a far better basis for an SLA than an aspiration.
Mistakes to avoid
- Targets nobody would notice missing. If users wouldn't feel a breach, the SLO is measuring the wrong thing.
- 100% targets. They leave no budget, so every change becomes a violation5.
- A policy without a signature from product. Then it is an engineering wish, not an agreement.
- Never revisiting. Review targets quarterly, as the Workbook's document template expects4.
How I can help
As a fractional CTO, I set up SLOs, error budget policies and on-call practices that fit the size of the team, so reliability decisions stop depending on the week you're having. Or analyse your challenge and bring the result to a call.
- 1
- 2
- 3
- 4
- 5