A practical SLO and error budget template helps platform teams turn reliability expectations into reviewable decisions. This guide explains how to choose useful SLIs, set service level objectives, calculate error budgets and burn rates, assign ownership, and connect reliability signals to release planning without making targets harder to understand than the services they protect.
Overview
A service level objective (SLO) is a reliability target for a service over a defined measurement window. It is usually expressed as a percentage or threshold, such as successful requests over 30 days or the proportion of requests completed below a chosen latency limit. An SLO is more actionable than a vague goal such as “keep the service reliable” because teams can measure it, review it, and use it to guide trade-offs.
An error budget is the amount of unreliability permitted by the SLO. If the target is 99.9% successful requests during a window, the error budget is the remaining 0.1% of eligible requests. The budget is not permission to cause failures. It is a decision tool that helps a team balance delivery speed with reliability work.
For platform engineering teams, SLOs should be visible in the internal developer platform or the team’s normal operational workflow. A service catalog can link each service to its SLO definition, dashboard, alert policy, owner, escalation path, and current budget status. This avoids treating reliability as a separate document that no one checks after launch.
Use the following worksheet for each important service:
- Service: What user-facing or internal capability is being measured?
- Owner: Which team is accountable for the service and its target?
- Users and dependency: Who relies on the service, and which dependencies affect the measurement?
- SLI: What observable event represents successful service?
- SLO: What target must the SLI meet?
- Window: Over what rolling or calendar period is the target evaluated?
- Error budget policy: What changes when the budget is healthy, low, or exhausted?
- Dashboard and alerts: Where can engineers inspect the result and receive actionable notifications?
- Review date: When will the team validate the target and its assumptions?
How to estimate
Start with the user journey rather than the telemetry already available. Ask what failure would prevent a user or dependent system from completing a meaningful action. For an API, the SLI might measure valid responses among eligible requests. For a queue, it might measure messages processed within an agreed time. For a platform capability, it might measure successful environment provisioning or deployment completion.
Then define the numerator and denominator precisely. An availability SLI can be represented as:
Availability = successful eligible events ÷ total eligible events × 100
Exclude events only when there is a documented reason and a reliable way to identify them. For example, a request rejected because of an invalid client payload may not represent a service failure, while a timeout caused by the service usually does. Ambiguous exclusions make the target appear healthier without improving the user experience.
For latency, define the eligible requests, the measured boundary, and the threshold:
Latency SLI = requests completed within the threshold ÷ total eligible requests × 100
A latency SLO should not rely only on an average. Averages can conceal a slow subset of requests. A threshold-based ratio, percentile view, or separate objective for critical operations usually gives the team a clearer signal. Choose the simplest form that reflects the actual user experience and can be queried consistently.
Calculate the budget in events as well as time where possible. If a service receives 2,000,000 eligible requests in a window and has a 99.9% availability target, the allowed unsuccessful events are:
2,000,000 × 0.001 = 2,000 events
For a time-based objective, a 99.9% target over a 30-day window permits approximately 0.1% of the window as unavailable time. The exact conversion depends on the window definition and whether the team measures calendar time, eligible request time, or another denominator. Record the method in the SLO documentation so that engineers do not interpret the budget differently.
Burn rate compares the rate at which the budget is being consumed with the rate that would use the full budget by the end of the window:
Burn rate = observed budget consumption rate ÷ planned budget consumption rate
A burn rate of 1 means the budget is being consumed at the planned rate. A rate above 1 indicates that the current failure pattern would exhaust the budget early if it continued. Use short windows to detect severe incidents and longer windows to confirm sustained degradation. Alert thresholds should lead to a response, not simply produce more dashboard activity.
Inputs and assumptions
Before approving an SLO, document the assumptions that make the calculation meaningful.
- Measurement boundary: State whether the metric begins at the edge, gateway, application, dependency call, or another point. A platform team and an application team may otherwise count different failures.
- Eligibility rules: Define health checks, retries, client errors, planned maintenance, administrative traffic, and synthetic requests. Do not exclude categories merely because they make the result worse.
- Window type: Rolling windows support continuous review, while calendar windows may fit reporting or operational processes. Choose one and keep it stable enough for comparison.
- Service criticality: A customer-facing checkout path may need a different target from an experimental internal tool. Do not assign a demanding target without a corresponding operational reason.
- Dependencies: Decide whether dependency failures count against the service. If the service owns the user experience, the user-facing SLO may need to include them even when another team owns the underlying component.
- Data quality: Confirm that logs, traces, metrics, and status events are retained long enough to evaluate the window. Missing telemetry should be visible rather than silently treated as success.
- Ownership: Name the team responsible for interpreting the metric and taking action. A target without an owner is a report, not an operating mechanism.
A useful error budget policy describes actions at several states. When the budget is healthy, the team can continue planned delivery while reserving capacity for routine reliability work. When consumption accelerates, the team investigates the cause, reviews risky changes, and may increase validation or rollout controls. When the budget is exhausted, the team may pause selected nonessential releases and prioritize remediation, provided this policy has been agreed in advance. The policy should identify exceptions for urgent security fixes, compliance work, or changes required to restore service.
Keep the policy proportional to the service. A platform engineering organization can provide a standard template, dashboard, and alerting integration, but service owners should still validate the SLI and the operational consequences.
Worked examples
Example 1: API availability. A team measures 500,000 eligible requests in a rolling window. The SLO is 99.95% successful responses. The budget is 0.05%, or:
500,000 × 0.0005 = 250 unsuccessful requests
If 100 requests have failed, the team has consumed 40% of the event budget. That number alone does not indicate an emergency; the team should also inspect the time remaining, the recent burn rate, the cause of failures, and whether the failures are concentrated in a critical operation.
Example 2: Latency. A deployment service sets an SLO that 99% of valid deployment requests complete within 10 minutes during a rolling window. The team measures 1,200 eligible requests, of which 1,170 meet the threshold. The result is:
1,170 ÷ 1,200 × 100 = 97.5%
The objective is missed, but the calculation should trigger investigation rather than an automatic conclusion. Check whether the threshold is applied at the correct boundary, whether queued and cancelled deployments are handled consistently, and whether a single infrastructure event dominated the result.
Example 3: Burn-rate decisions. Suppose a service has a 99.9% availability SLO and a short-term burn rate above 1. The team can use a review table such as this one:
| Observed condition | Suggested response |
|---|---|
| Budget consumption is within the planned rate | Continue normal delivery and review reliability work during the regular operating cycle. |
| Short window shows elevated burn | Investigate recent changes, inspect dependencies, and increase attention to active degradation. |
| Short and long windows show sustained high burn | Escalate the incident or reliability work and consider pausing risky releases. |
| Budget is exhausted | Apply the agreed error budget policy, prioritize recovery, and document the release decision. |
These are decision patterns, not universal thresholds. Each team should connect them to its incident response runbook, deployment controls, and service ownership model. For related operational work, see the incident response runbook template and the internal developer platform roadmap.
When to recalculate
Review an SLO before launching a new service, after a major architecture or traffic change, and after an incident reveals that the metric did not represent user impact. Recalculate when request volume, workload shape, dependency boundaries, retention, or instrumentation changes. Also revisit targets when teams repeatedly miss them without a clear reliability decision, or when a target is always met but no longer distinguishes meaningful performance.
A monthly review agenda can keep the process lightweight:
- Confirm the SLI query, exclusions, data completeness, and dashboard links.
- Review SLO attainment, remaining budget, burn-rate alerts, and the largest contributors to consumption.
- Compare recent releases, incidents, dependency events, and operational changes with the reliability signal.
- Decide whether to continue delivery, add safeguards, prioritize remediation, or revise an assumption.
- Record an owner, decision, due date, and next review date.
Refresh the worksheet whenever observability queries, alerting behavior, terminology, or implementation details change. If your platform provides reusable service templates, encode the fields and policy links there, but require a human review before enabling an SLO in production. A small, understood set of objectives is more useful than a large catalog of targets that teams cannot explain or act on.
