A service level indicator measures a user-relevant property such as successful requests or acceptable latency. A service level objective sets a target for that indicator over a window. The remaining tolerated bad events form an error budget, which helps teams balance release pace and reliability investment.
Who this is for: Product, engineering, and operations teams agreeing how reliable an online service should be and how to measure it.
- Define indicators at the user-facing boundary and count valid events with explicit good and total criteria.
- Set objectives from user and business needs, not from the best number the current dashboard happens to show.
- Connect error-budget consumption to agreed engineering actions before reliability becomes urgent.
Begin with a critical user journey
Choose an action users recognize, such as loading a product, submitting an order, or processing a queued job by its deadline. Define where the journey starts and ends, which users and regions count, and what outcome is good. Infrastructure uptime may support the journey but is rarely the complete user experience.
Limit the first SLO set to important journeys. Too many objectives divide attention and create reporting work without changing decisions. Include product owners because the value and consequence of failure determine the target. Record dependencies that are inside the measured path even when another team or provider operates them.
Specify the indicator precisely
A request-based availability indicator can be good eligible requests divided by total eligible requests. Define eligible traffic, success status, client-caused errors, retries, health checks, and planned maintenance. A latency indicator counts requests completed under a threshold. Distribution and journey segmentation may reveal harm that one global average hides.
Data source and collection behavior belong in the definition. Edge measurements may represent users better than process metrics, while synthetic checks can detect total absence of traffic. Explain missing telemetry and delayed events. Validate the indicator against real incidents so a customer-visible failure produces the expected bad events.
Set target and window
An objective such as 99.9 percent successful eligible requests over 28 days allows 0.1 percent bad events. More nines can be disproportionately expensive and may exceed dependencies or customer needs. Consider user alternatives, contract commitments, traffic shape, and the cost of engineering plus capacity needed to reach the target.
A rolling window reflects recent experience continuously; a calendar window can align with reporting or agreements. Avoid excluding broad maintenance periods if users still experience them unless the exclusion is explicit and justified. External service-level agreements may differ from internal objectives and normally include legal terms beyond an engineering measurement.
Operate with an error budget
The error budget converts the objective into tolerated bad events. Track both remaining budget and burn rate, which shows how quickly it is being consumed. Fast burn should trigger urgent investigation; slower sustained burn may lead to planned reliability work. Use several time windows to detect severe events without paging on every small fluctuation.
Agree actions for healthy, concerning, and exhausted budget states. Teams might slow risky releases, prioritize a known failure mode, or require additional review. The policy should encourage learning, not hide incidents. Review objectives when journeys, traffic, dependencies, or business consequences change, but do not weaken a target merely to make reports green.
Define an order-submission SLO
A retailer wants a shared reliability target for customers placing valid orders through its web checkout.
- Define total events as valid submission attempts reaching the checkout edge and good events as confirmed orders within eight seconds.
- Exclude demonstrably invalid customer input but count server errors, internal timeouts, and failed dependencies experienced by the customer.
- Choose a 28-day objective based on sales impact, support burden, dependency capability, and planned engineering investment.
- Create fast- and slow-burn alerts plus a policy that pauses high-risk checkout changes when budget consumption crosses the agreed threshold.
SLO definition sheet
Complete one sheet per critical user journey and review it with product and engineering owners.
- Journey, users, start, successful end, consequence of failure, and accountable service owner.
- Total-event query, good-event query, exclusions, threshold, dimensions, and telemetry source.
- Objective percentage, rolling or calendar window, rationale, dependencies, and related agreement.
- Error-budget calculation, burn-rate windows, alert thresholds, and missing-data behavior.
- Healthy, warning, exhausted, and recovery actions with review cadence and change history.
Common mistakes
- Defining an SLO as server process uptime while users depend on several failing downstream services.
- Choosing 100 percent as an aspiration without pricing the architecture and operational constraints it implies.
- Creating an error-budget dashboard with no agreed decision when the budget burns too quickly.
Try one
A service reports 99.99 percent host uptime, but ten percent of purchase attempts fail at a payment dependency. Is host uptime a useful SLO?
It may be a diagnostic metric, but it is not an adequate purchase-journey objective. A strong answer measures eligible purchase attempts and successful timely outcomes at the user boundary, counts dependency failures, defines a justified target and window, and validates the indicator against this incident. It connects budget burn to corrective action.
Sources
- AWS Well-Architected Reliability PillarOfficial AWS design principles and practices for reliable workloads and recovery planning.
- Amazon CloudWatch documentationOfficial AWS overview of metrics, alarms, dashboards, logs, and application monitoring.