SLOs and Error Budgets for Small Engineering Teams

SLOs and error budgets become useful when they change a decision. If the team measures availability but continues shipping exactly the same way after repeated failures, it has a dashboard rather than a reliability policy.

For a small engineering team, I would start with one important user journey, one measurable objective, and one agreed response when the objective is missed. More coverage can follow after the first objective proves useful.

Choose the outcome users need

Google's SRE Workbook describes service level indicators as measurements of service behavior and SLOs as reliability targets. It emphasizes stakeholder agreement and a policy that uses the resulting error budget for decisions. Its examples include ratios of good events to eligible events. Implementing SLOs.

Start with a sentence a product owner can understand: “Customers can successfully submit an order,” or “A report becomes available within the promised processing interval.” CPU usage may help explain failure, but it is usually several steps removed from these outcomes.

Define the population carefully. Does a rejected invalid request count? What about a client cancellation after the server stalls? What about requests that never reach the application because the edge is unavailable? An apparently precise percentage can hide a vague denominator.

Write the eligibility rules before looking at whether the objective passes. Otherwise, the temptation to exclude awkward failures can turn the SLO into a measure of what the team finds convenient to count.

Make the calculation inspectable

Consider an invented request-based objective of 99.5% successful eligible operations over a chosen review window. If that window contains 200,000 eligible operations, the allowed bad-event count is:

200,000 × (1 - 0.995) = 1,000 bad operations

If 300 eligible operations have failed, 700 remain in that example budget. These are illustrative numbers, not a recommended target or observed workload.

A request budget is not automatically a downtime budget. A brief failure during peak usage can consume many more requests than a longer failure during quiet hours. Keep the unit explicit in dashboards, incident reviews, and release discussions.

Also define how incomplete telemetry is represented. If the measurement pipeline disappears, treating missing samples as perfect service makes the objective unreliable. I would display measurement gaps separately and require investigation before using that period to justify a risky release.

Decide how latency and success interact

A response can be technically successful yet too slow to be useful. Decide whether latency belongs in the same good-event definition or in a separate objective. The best choice is the one the team can explain and act on consistently.

For example, a hypothetical report-generation service might have a completion objective and a freshness objective. Combining everything into a single percentage can make it difficult to tell whether work is failing or merely falling behind. Splitting every possible behavior into a separate SLO creates a different problem: nobody knows which failure deserves attention.

I would prefer a few objectives with clear users and decisions over exhaustive instrumentation. Review them against support cases and observed incidents. When customers report pain that the SLO calls healthy, investigate the measurement design rather than insisting the customers are wrong.

Write the error-budget policy before the outage

Google publishes an example policy that changes release behavior when the error budget is exhausted while making room for urgent issues and security fixes. It frames the policy as a way to prioritize reliability work rather than punish teams. Example error-budget policy.

A small-team policy can fit in a short document:

This table is a suggested starting point, not a standard. Name the decision owner, the review window, and how exceptions are recorded. A security fix that reduces immediate risk may need a different treatment from a cosmetic feature release.

Avoid automatic freezes with no path to improvement. If the service is outside objective because a bug needs deployment, the policy must allow the fix. The purpose is to make risk decisions explicit, not create procedural deadlock.

Use incidents to refine the objective

After an incident, ask how much user harm the objective captured and what it missed. Did retries inflate the denominator? Did a failed region disappear from the data? Did one large customer experience severe disruption while the aggregate looked acceptable?

These questions do not imply every service needs per-customer objectives. They identify where aggregation changes the meaning of the signal. Add dimensions only when they support a real operational decision and can be measured responsibly.

Keep the objective stable long enough to learn from it, but version meaningful changes. If you redefine eligible requests halfway through the reporting period, annotate the result rather than pretending the trend is directly comparable.

The connection-pool overload exercise is one way to investigate a latency objective under pressure. The restore-drill guide addresses recovery objectives when ordinary service cannot be maintained. An SLO should inform a decision to repair, slow down, or proceed.