This SLI and SLO guide gives engineering teams a repeatable way to choose reliability indicators, set measurable service objectives, calculate error budgets, and use those results in release and planning decisions. It also includes worksheets, examples for APIs and background jobs, an error-budget policy template, and a quarterly review checklist.
Overview
Service-level indicators (SLIs), service-level objectives (SLOs), and error budgets are most useful when they help a team make a decision. They should not become a collection of dashboard numbers that nobody reviews. The goal is to connect user experience, engineering work, and operational risk in a shared framework.
An SLI is a measured aspect of service performance. Examples include the proportion of successful API requests, request latency below an agreed threshold, or the percentage of scheduled jobs completed on time.
An SLO is the target for that indicator over a stated time window. For example, a team might define an objective that 99.5% of valid API requests succeed during a rolling 30-day period. The target is incomplete unless the team also defines the measurement window, eligible requests, exclusions, and data source.
An error budget is the amount of unreliability permitted by the SLO. If the objective is 99.5% successful requests, the corresponding budget is 0.5% unsuccessful requests within the same window. This budget is not permission to create failures. It is a planning tool that helps teams balance delivery speed with reliability work.
Good SLOs support collaboration between developers, platform engineers, product managers, and incident responders. They provide a common basis for discussing whether a release is safe, whether reliability work should take priority, and whether an incident exposed a weakness in the objective itself.
How to estimate reliability targets
Start with the user journey rather than the telemetry already available. Ask what a customer, internal user, or dependent service needs from the system. Then choose an indicator that measures that outcome directly enough to guide action.
- Name the service promise. Write the outcome in plain language, such as “users can submit a payment request” or “the nightly data export is available before the business day begins.”
- Choose the SLI event. Define the numerator and denominator. For availability, this might be successful eligible requests divided by total eligible requests. For a job, it might be completed jobs divided by scheduled jobs.
- Set the evaluation window. A rolling window is useful for ongoing release decisions, while a calendar window may align with reporting or operational reviews. Use the same window for the SLO and its error budget.
- Select a target that matches user needs. Do not choose a target simply because a monitoring system makes it easy to display. Consider business impact, dependencies, historical performance, and the cost of improving the target.
- Convert the target into a budget. Use:
error budget = 1 - SLO target. For an availability target of 99.5%, the budget is 0.5% of eligible events during the selected window. - Define the decision attached to the result. State what happens when the budget is healthy, nearly exhausted, or exhausted. Without this step, the SLO remains informational rather than operational.
A practical SLI-to-SLO worksheet can use these fields:
- Service and owner
- User journey or dependency being protected
- SLI name and plain-language definition
- Numerator, denominator, and exclusion rules
- Data source, query, and dashboard
- Evaluation window
- SLO target and calculated error budget
- Alert thresholds and review owner
- Release, escalation, and remediation actions
Inputs and assumptions
Reliability estimates are only as useful as their definitions. Record assumptions before comparing services or using an objective in a release decision.
Define eligible events
For an API, decide whether the denominator includes authenticated and unauthenticated traffic, health checks, retries, rejected requests, and requests intentionally blocked by validation. A success SLI should generally reflect whether the service fulfilled an eligible request, not merely whether a process returned a response.
Separate user impact from internal symptoms
CPU utilization, queue depth, restart counts, and alert volume can help explain an SLO result, but they are not automatically user-facing SLIs. Keep diagnostic metrics alongside the objective rather than substituting them for it.
Choose a small set of indicators
Most services need only a few meaningful indicators to begin. Common categories are availability, latency, freshness, correctness, and completion. More indicators can improve coverage, but they also increase review and alerting overhead. Add one when it represents a distinct failure mode or user promise.
Make ownership explicit
Assign an owner for the measurement definition, dashboard, alert routing, and periodic review. A shared service may need both a product-facing owner and a platform or operations contact. Ownership should include responsibility for correcting the SLI when the service changes.
Use burn rate carefully
Budget consumption can be expressed as the portion of the permitted failure allowance already used. A simple estimate is:
budget consumed = observed failure rate / allowed failure rate
This ratio is useful for planning, but short windows can be noisy. Pair a fast signal for significant ongoing impact with a longer window for release and planning decisions. Avoid treating a single transient data point as proof that the service has permanently missed its objective.
Worked examples
Example 1: Public API availability
Suppose an API team defines an SLI as successful eligible requests divided by total eligible requests. It chooses a 99.5% objective over a rolling 30-day window. The allowed failure rate is therefore 0.5%.
If the window contains 2,000,000 eligible requests, the approximate failure allowance is:
2,000,000 × 0.005 = 10,000 failed requests
The team should document what counts as a failed request and whether retries are counted as separate events. If a release consumes most of the budget, the team may pause additional risky changes, investigate the release, or prioritize reliability work. The exact response belongs in the team’s policy; the calculation simply makes the trade-off visible.
Example 2: Background job completion
A reporting service runs scheduled jobs and defines success as a completed report made available before its agreed deadline. Its SLI is on-time completed jobs divided by scheduled jobs. With a 98% objective over a review window containing 500 scheduled jobs, the allowance is:
500 × 0.02 = 10 jobs
This objective should distinguish a missed deadline from a job that was never scheduled, manually cancelled, or blocked by an invalid customer input. Those cases may need separate metrics. The team should also review whether ten missed jobs represent an acceptable operational risk; the arithmetic does not determine the business target.
Example 3: Latency objective
For latency, use a threshold-based indicator rather than an average alone. For example, define the SLI as requests completed within an agreed latency threshold divided by eligible requests. A percentile dashboard can help investigate distribution, while the SLO calculation uses the explicitly defined pass or fail condition. This keeps the objective tied to a user-visible experience and avoids allowing a small number of very slow requests to disappear inside an average.
Error-budget policy template
Teams can adapt the following policy:
- Healthy budget: normal delivery and reliability work proceed through the usual review process.
- Budget at risk: the service owner reviews recent changes, increases investigation priority, and considers safer rollout controls.
- Budget exhausted: pause or narrow changes that could affect the SLO until the team has an approved mitigation or recovery plan. Critical security and corrective changes remain subject to risk-based review.
- After an incident: confirm whether the SLI captured the user impact, update the objective or exclusions if necessary, and assign follow-up work with an owner.
When to recalculate and review
Revisit an SLI and SLO whenever the service, user journey, or operational decision changes. A quarterly reliability review is a useful baseline, but do not wait for the calendar if the objective has stopped representing reality.
Recalculate after these changes
- A major API, workflow, dependency, or architecture change
- A new customer segment or critical use case
- A change to traffic volume, job frequency, or data-retention behavior
- An incident showing that the current SLI missed meaningful user impact
- A change in deployment strategy, ownership, or alerting integration
- Repeated budget exhaustion without a clear decision or remediation path
Quarterly review checklist
- Confirm that each SLI still maps to a real user or business outcome.
- Test the numerator, denominator, exclusions, and data pipeline with recent examples.
- Review budget consumption, alert noise, incidents, and release outcomes together.
- Check whether the target is too loose to guide action or too strict to be economically useful.
- Verify dashboard, alert, escalation, and ownership details.
- Record decisions, changed assumptions, and follow-up work in the team’s planning system.
Keep the worksheet versioned with the service documentation so developers, incident responders, and platform teams use the same definitions. For implementation context, connect the objective to your telemetry design with the OpenTelemetry implementation guide, and pair it with the observability and incident response checklist. The most effective SLO practice is not choosing a perfect number once; it is maintaining a clear, reviewable agreement about what reliability means and what the team will do when the evidence changes.
