Reliable services need measurable targets, not vague promises. This guide explains how to choose useful service level indicators (SLIs), set service level objectives (SLOs), calculate an error budget, and use burn-rate signals to make release and incident decisions. It includes availability, latency, and freshness examples, plus templates you can adapt to a new or existing service.
Overview
An SLI is the measurement of a user-visible service behavior. An SLO is the target for that measurement over a defined time window. The error budget is the amount of unreliability allowed before the service misses its SLO.
For an availability SLO, the basic relationship is:
Error budget percentage = 100% − SLO percentage
If a service has a 99.9% availability objective over 30 days, its error budget is 0.1% of the eligible service time. If the service measures successful requests instead of time, the budget is 0.1% of eligible requests. The measurement method matters: a maintenance window, failed dependency call, or client cancellation should only be excluded when the service definition explicitly explains why.
A useful SLO has four properties:
- User relevance: It measures an outcome users experience, such as successful checkout requests or fresh search data.
- Clear eligibility: It states which requests, events, tenants, regions, or records are included.
- A defined window: It identifies whether the target is evaluated over a calendar month, rolling period, or another agreed interval.
- An operational consequence: The team knows what changes when the error budget is healthy, low, or exhausted.
SLOs are not a replacement for dashboards or alerts. They provide a decision framework that connects observability data to engineering priorities.
SLI examples by service type
| Service type | Useful SLI | Example SLO expression | Common caution |
|---|---|---|---|
| HTTP API | Successful request ratio | Successful eligible requests / total eligible requests | Define which status codes and client errors count. |
| User-facing web page | Latency at a chosen percentile | At least 99% of eligible page loads below the target | Separate backend latency from full user experience when needed. |
| Asynchronous worker | Job completion or processing delay | At least 99% of eligible jobs complete within the target time | Track retries, duplicate work, and permanently failed jobs. |
| Data pipeline | Freshness | At least 99% of datasets are updated within the freshness window | Define the source timestamp and what makes a record eligible. |
| Storage service | Read or write success | Successful operations / eligible operations | Distinguish temporary throttling from invalid requests. |
How to estimate
Start with the user journey rather than the available metric. Ask what failure would prevent a user or downstream system from completing its task. Then select the narrowest reliable measurement that represents that failure.
- Describe the service promise. Write one sentence, such as “Customers can submit an order and receive an accepted response.”
- Choose the SLI event. Identify the request, transaction, job, or data object that represents the promise.
- Define good and bad outcomes. For example, an HTTP request may be good when it returns an accepted response within the latency threshold.
- Choose the evaluation window. A rolling window can support ongoing burn-rate decisions; a calendar window may fit reporting and planning. Use one consistently for the policy.
- Set an initial target. Base it on user expectations, product commitments, observed behavior, and the cost of improving reliability. Avoid choosing a high target simply because it sounds precise.
- Calculate the budget. Convert the target into an allowed count of bad events or allowed duration.
- Test the definition against historical data. Look for missing telemetry, traffic changes, excluded failures, and periods where the SLI does not represent the actual user experience.
For request-based availability, use:
SLI = good requests / valid eligible requests
Allowed bad requests = eligible requests × error budget percentage
For time-based availability, use:
Allowed unavailable time = eligible service time × error budget percentage
Latency objectives require a different calculation. If the target is that 99% of requests complete below a threshold, calculate the proportion of eligible requests meeting that threshold. Do not average latency unless an average is genuinely useful for the user journey; a small number of very slow requests can disappear inside an average.
Inputs and assumptions
Record the assumptions beside every SLO. This prevents a dashboard from becoming the only place where important interpretation rules exist.
SLO definition template
Service: [name and owner]
User promise: [what users or downstream systems need]
SLI: [good events] / [eligible events]
Eligibility: [routes, regions, tenants, job types, or records included]
Exclusions: [explicitly excluded events and the reason]
Objective: [target percentage or latency threshold]
Window: [rolling or calendar period]
Owner: [team responsible for measurement and response]
Be careful with exclusions. Excluding failures caused by invalid user input may be reasonable for a success-rate SLI, but excluding dependency failures can hide a real user-impacting problem. Document exclusions in plain language and review them after incidents.
Telemetry must support the definition. Distributed traces can help connect a user request to downstream work, while metrics are often better suited to stable SLI calculations and long-term burn-rate alerts. Logs can supply diagnostic detail but should not be the only source for a critical SLO. An OpenTelemetry implementation guide can help teams plan consistent instrumentation across services.
Error-budget policy template
When the budget is healthy, the team may proceed with normal feature work, reliability improvements, and planned releases. When consumption accelerates, the team should investigate the cause and reduce avoidable risk. When the budget is exhausted, the default response can be to prioritize restoration and reliability work over nonessential risky changes until the service returns to an agreed state.
Write the policy so it answers three questions:
- What metric or burn-rate condition changes the team’s response?
- Who can pause, limit, or approve a risky release?
- What evidence is required before normal release activity resumes?
Burn-rate alerting
Burn rate compares the current rate of budget consumption with the rate that would use the entire budget during the evaluation window. A burn rate of 1 means the service is consuming budget at the planned maximum pace. A higher value indicates that the budget will be depleted sooner if the rate continues.
Use at least one short observation window for fast incident detection and one longer window to reduce reaction to brief noise. The exact windows and thresholds should reflect traffic volume, incident response capacity, and the cost of false alerts. Alerting should link to a runbook that explains how to confirm user impact, identify the affected slice, and decide whether to roll back or pause deployment.
Worked examples
Availability by request count
Assume an API records 2,000,000 eligible requests during its evaluation window and has a 99.9% availability SLO. The error budget is 0.1%, so the allowed bad-request count is:
2,000,000 × 0.001 = 2,000 bad requests
If monitoring shows 1,400 bad requests, the service has used 70% of its request-based budget. That does not automatically mean a release must stop, but it should prompt investigation, especially if consumption is concentrated in a recent deployment or a critical customer path.
Availability by time
Assume a service evaluates 30 days of eligible time and uses a 99.95% availability objective. The error budget is 0.05%. Calculate the eligible duration in minutes and multiply by 0.0005. The result is the maximum unavailable duration for the defined window. If scheduled maintenance is excluded, the policy must state how that exclusion is measured and approved.
Latency
Suppose the objective is: “At least 99% of eligible checkout requests complete within 800 milliseconds.” During a review period, 100,000 requests are eligible and 98,900 finish within the threshold. The measured SLI is 98.9%, below the 99% objective. The latency error budget is therefore consumed for the requests that exceeded the threshold. The next step is to segment the result by endpoint, region, dependency, and deployment version rather than relying on one aggregate number.
Freshness
For a reporting pipeline, define freshness as the time between the source event timestamp and the dataset’s available timestamp. If the SLO says 99% of daily datasets are available within 15 minutes, record each eligible dataset, its actual delay, and whether it met the threshold. A dashboard showing only the latest successful run may miss intermittent delays or stale partitions.
Release decision
Before a risky release, check current budget remaining, recent burn rate, open reliability incidents, and the release’s expected blast radius. If a short-window burn alert is active, pause the rollout and verify whether the release caused the change. For gradual delivery, combine the SLO signal with a controlled rollout strategy such as canary or blue-green deployment; the deployment strategy comparison provides a framework for choosing between them.
When to recalculate
Revisit SLOs whenever the service, its users, or its observability changes. A quarterly review is a practical baseline, but do not wait for the calendar if a major event occurs.
- After an incident: Confirm that the SLI captured the user impact. If it did not, improve instrumentation or change the definition.
- Before launching a new service: Define ownership, eligibility, dashboards, alerts, and the initial error-budget policy before calling the service production-ready.
- After a major architecture change: Recheck sampling, asynchronous processing, dependency boundaries, and regional coverage.
- When traffic or usage patterns change: Request-based budgets and latency distributions may behave differently at a new scale.
- When release risk changes: New deployment methods, dependencies, or customer workflows may require additional SLIs.
- When alerts are noisy or silent: Tune thresholds, windows, routing, and runbook instructions based on observed response quality.
For the next review, export the SLO result, budget consumption, burn-rate incidents, notable releases, and unresolved measurement gaps. Ask whether the target still represents a meaningful user promise and whether the team can act on the signal. Keep the definition, policy, dashboard query, and runbook together in version control so changes receive the same review as application configuration.
Finally, turn the result into an operating decision: continue normal releases, add reliability work to the next iteration, limit rollout size, or pause risky changes until the service is understood and stable. An SLO becomes useful when it changes what the team does—not merely when it appears on a dashboard.
