Software ArchitectureAtlas

Software Architecture Atlas

Gain an overview. Understand the connections.

ApproachChapter III · Operations · Building block 8 of 10

SLIs, SLOs & error budgets

An SLI is a measure of experienced service quality. An SLO sets a target over a defined time window; the error budget describes the permitted proportion of missed events.

By Michael Meierhoff · Meierhoff Systems

  1. TargetThe share that should succeed.
  2. Error budgetThe rest to the goal is the permitted deviation.
  3. ReactionA spent budget changes what the team does.

Context

Why this is important

Without a measurable goal, the team argues whether the shop is running well enough and when stability comes before new functions. SLI, SLO and Error Budget make this decision verifiable. Observability and deployment deepen their own building blocks.

This building block combines measurement, goal and action rule. Observability delivers signals; deployment and rollout deliver concrete change decisions.

At a glance · From measurement to response

The SLI measures quality, the SLO sets the target, and the remainder up to the target is the error budget.
Shop example · Playing through stages

From Target Value to Error Budget

The team evaluates successful order confirmations that become visible in the shop within two seconds. A monthly goal and a response rule control risky changes.

This is how you read the picture

  1. Target You choose the target value, for example 99,5 % over 30 Days.
  2. Error budget In case of: 99,5 % and 50.000 Orders are 250 Incorrect orders allowed.
  3. Reaction Disruption colors the budget; if exceeded, risky rollouts pause.
  • 0.5 %Error budget (share)
  • 250Allowed misorders

In case of: 99,5 % over 30 days and 50.000 Orders may be placed with the share 0,5 % the confirmation in 2 s missed: 250 Orders.

Values illustrative

Choose an SLO for 30 Days at 50.000 Orders per month. Turn on the disturbance and read off the remaining budget and response.

Benefits & limitations

Helps if:

  • User success can be formulated as valid events and a measurable quality goal.
  • Product and operations teams gain a shared basis for balancing reliability and planned changes.

Boundaries

  • Averages hide slow tail cases; add percentiles and check which user groups the denominator includes.
  • A single target mixes critical and optional functions; define separate indicators when consequences or tolerances differ.
  • The target is only as good as its measurement; Observability supplies the data, while the response policy governs release decisions.

In practice

  1. Define user-relevant events. Describe what counts as a valid attempt and when it succeeds from the user’s perspective. State the measurement point and exclusions. The resulting SLI has a numerator and denominator that different teams interpret consistently.
  2. Set the target and budget. Choose a target and time window that fit the business impact and validated operational data. Define how consumption is calculated and shown across different windows. This makes target attainment and remaining headroom transparent.
  3. Connect policy to action. Define owners, responses to rapid consumption and criteria for resuming regular work. Test the policy against historical or simulated measurements. This produces a usable decision framework linking targets to concrete actions.
Read the detailed explanation

A Service Level Indicator (SLI) defines the population, measurement point and rule for good events. A Service Level Objective (SLO) sets a target over a time window. The error budget is the proportion of bad events allowed within that target. Its burn rate can be derived from Observability signals and makes previously defined Quality attributes concrete.

The numerator, denominator, exclusions and time window determine the meaning of an SLI. Different user functions may therefore need different targets. A policy defines how rapid budget consumption affects operations, releases or remediation. The error budget provides a shared framework for operational and release decisions; representative measurements and clear rules determine its value.

SRE (Site Reliability Engineering) is an approach originating in operations at Google that uses SLOs and error budgets.

Check your understanding

Test yourself in three stages

  1. ReadingCheck in the picture

    How many misorders does an SLO of 99,5 %and what remains after the disorder with 120 Mistakes?

    View the solution with justification

    250 Incorrect orders allowed ()0,5 % from 50.000). After 120 Mistakes remain 130The team observes the consumption.

  2. ApplyingTransferred to a new situation

    A rollout consumes the error budget quickly, the next risky change is pending. What does the policy say?

    View the solution with justification

    Fast consumption pauses risky rollouts. The capacitance goes into stabilization until the measurement is again in the agreed course.

  3. EvaluateWeighing an alternative

    The team agreed on a stricter SLO than 99,5 %. What speaks in favour, what speaks against?

    View the solution with justification

    For this: The quality goal for confirmation increases. On the other hand, the error budget is shrinking, and risky rollouts are paused earlier. The value must match the user expectation and measurement quality.

Explore further

These building blocks continue the thoughts of this page.

OperationsObservabilityObservability combines signals that let you inspect a system's internal state.Opening OperationsDeployment & rolloutDeployment and rollout distribute software changes to the runtime environment under control.Opening RequirementsAvailabilityYou determine when a function is available to users and how reliably it is provided.Opening

References

Continue on the learning path

Next in Runtime & operations: Deployment & rollout.

10 Building blocks

Continue withDeployment & rollout