SLIs, SLOs and error budgets: measuring service reliability

An SLI measures actual service quality, an SLO defines the target, and an error budget turns the gap below 100% into a manageable amount of risk. Together they let business and engineering discuss the user outcome rather than servers and green dashboards.

“The service must always work” does not explain how much to invest, when to stop releases or which degradation customers notice.

Terms

• Service Level Indicator: a measured quality such as success, latency, freshness or completeness.
• Service Level Objective: the target value over a defined window.
• Service Level Agreement: a commitment with defined consequences.
• Error budget: the permitted share of bad events within the SLO window.

A 99.9% success SLO over 30 days permits 0.1% bad events. Converting that directly into downtime is only accurate for a continuously measured service; request and queue systems are usually better measured by events.

Start with the user journey

Infrastructure monitoring tells you whether a component is alive. An SLI should tell you whether the user obtained the intended result.

For an ordering flow, that may include delivery calculation, payment confirmation, order persistence and notification. Database CPU cannot replace end-to-end success: a busy server may still cope, while healthy hosts may hide a failing external dependency.

Choose useful SLIs

Availability

availability = good requests / valid requests

Define denominator exclusions in advance. A malformed client request may be excluded; an authentication failure caused by the identity provider may be a bad event.

Latency

latency SLI = requests faster than 500 ms / valid requests

An average hides the tail. Use the share within a user-relevant threshold, with P95/P99 for diagnosis.

Freshness and completeness

For data:

freshness = records updated within 10 min / expected records
completeness = processed valid records / received valid records

A successful loader response does not prove that every record reached the consumer.

For notifications, success may require a terminal status without duplication. See omnichannel transactional notifications.

Specify good events

Document the data source, event unit, good criterion, denominator, exclusions, window, telemetry delay, owner and validation method. If two teams calculate “availability” differently, they have different SLIs.

Set the first SLO

Do not copy 99.99% from a provider advertisement. Consider user expectations, historical quality, dependencies, improvement cost and the team’s response capability.

The first SLO should be achievable under normal operation and strict enough to reflect user pain. A 99.99% target on a service currently delivering 97.4% creates permanent violation rather than useful decisions.

Google SRE recommends stakeholder agreement and a policy that determines how the error budget changes priorities. Otherwise the SLO becomes another dashboard KPI.

Calculate the error budget

For a 99.9% objective:

error budget = 1 - 0.999 = 0.001

Across ten million valid operations, 10,000 may be bad.

For time-based measurement across 30 days:

SLO	Approximate unavailability
99%	7 h 12 min
99.9%	43 min 12 sec
99.95%	21 min 36 sec
99.99%	4 min 19 sec

Five minutes at peak may harm more operations than an hour overnight, which is why event-based measurement is often better.

Burn rate and alerts

A burn rate of 1 consumes budget at the allowed pace. A burn rate of 10 would exhaust a monthly budget in roughly three days if sustained.

Use multiple windows: a short one detects a sharp failure, while a longer one confirms persistence. Each alert should state the affected journey, current SLI and burn rate, start time, dashboard, recent changes, runbook and escalation owner.

Wake people for user harm or rapid budget consumption, not every diagnostic metric. CPU, queue depth and connections support diagnosis.

Error-budget policy

Agree decisions in advance:

State	Decision
Healthy	Normal change pace
Accelerated burn	Stronger review and fewer risky changes
Nearly exhausted	Reliability and remediation take priority
Exhausted	Pause non-essential change until control returns

Exceptions need an owner, rationale and expiry.

Composite and asynchronous systems

Do not mechanically multiply component SLOs and call the result a user SLO. Dependencies may run in parallel, use caches or serve only some requests. Measure the journey from outside and use component SLOs as team interfaces.

For queues and background work, measure completion before deadline, oldest valid message age, completeness, duplicates, permanent failures and time to the business outcome. Use TTL so a recovered queue does not deliver actions that are no longer useful.

Our IaaS comparison explains provider/customer responsibility, while infrastructure observability covers the telemetry.

Four-week adoption plan

1. Select one critical user journey and owner; define good and total events.
2. Compare telemetry with logs and support incidents; measure gaps and delay.
3. Use history and expectations to set an initial four-week SLO.
4. Add multi-window burn-rate alerts, runbooks and an error-budget policy.

Review the target after one or two windows. An SLO is a managed hypothesis about required reliability, not an eternal number.

Checklist

• The SLI expresses a user outcome.
• Good and total events are unambiguous.
• Data source and delay are known.
• Product, operations and business agree on the SLO.
• The error budget has an explicit window.
• Alerts use burn rate and multiple windows.
• Every alert has an action and runbook.
• The policy affects releases and priorities.
• Component health does not replace the user journey.
• Definition changes are transparent and prospective.

Conclusion

SLIs, SLOs and error budgets provide a shared language for business and engineering. Start with one user journey, measure good events, agree a realistic objective and define decisions before the budget burns.

The primary practical reference is Implementing SLOs in the Google SRE Workbook. Connect it to a disaster recovery plan and observability.

Next step: Logic Telecom can help select user-centred SLIs, validate telemetry and connect SLOs to operating procedures.