Service Level Objectives

A service level objective (SLO) defines an acceptable level of service using a measurement, a target, and an evaluation window. For example, a checkout API might require at least 99.9% of eligible requests to succeed over a rolling 30-day period. A separate latency objective might require 99% of eligible requests to complete within 500 milliseconds. These targets express customer expectations more directly than infrastructure measurements such as CPU utilization.

Distinguish an SLO from a service level indicator (SLI) and a service level agreement (SLA). The SLI is the measured behavior, such as the proportion of successful checkout requests. The SLO is the target for that indicator. An SLA is an agreement that establishes service commitments and commonly specifies consequences, such as service credits, when those commitments are missed. An internal SLO is often stricter than the corresponding SLA to provide an operational safety margin, but this is a design choice rather than a requirement.

Start with business outcomes and define exactly what counts as good service. Specify the user journey, eligible requests, success criteria, measurement location, evaluation window, and treatment of maintenance and missing data. An HTTP success response does not necessarily prove that an order was recorded correctly. Similarly, a server-side latency metric may omit network delays that customers experience. Use application instrumentation and external synthetic transactions where appropriate, and document any exclusions rather than silently removing failures.

The error budget is the allowed amount of failure implied by the objective. For a request-based 99.9% success SLO, one million eligible requests permit 1,000 unsuccessful requests within the evaluation window. For a time-based availability SLO measured continuously across 30 days, 99.9% allows 43.2 minutes of unavailability, while 99.99% allows 4.32 minutes. Request-based and time-based budgets are not interchangeable because traffic varies and partial failures affect different users.

Use the target to select a proportionate cloud architecture. A revenue-generating production service may justify multiple Availability Zones, redundant application instances, load balancing, database failover, and spare capacity. A development environment may tolerate a single instance and scheduled shutdowns if its agreed service hours and recovery expectations allow them. Non-production systems that support critical releases or shared testing can still require high availability. Workload classification should reflect business impact, not labels alone.

Higher objectives usually increase infrastructure cost and operational complexity. Multi-Region deployment can address regional failures, but adds replication, routing, consistency, and failover challenges. It is not automatically necessary for every production workload. Recovery time objectives and recovery point objectives complement SLOs by specifying restoration time and acceptable data loss; they do not replace measurements of ongoing service quality.

Provider SLAs do not automatically become the application's SLA or SLO. Review each dependency's coverage, deployment prerequisites, exclusions, and failure behavior. Dependencies in a serial request path can reduce end-to-end availability, while redundancy only helps when failures are sufficiently independent and failover actually works. Multiple instances in one Availability Zone do not protect against that zone becoming unavailable.

Operationalize SLOs through dashboards, error-budget consumption alerts, and tested response procedures. Burn rate measures how quickly the service consumes its allowed failure budget relative to the expected rate; sustained rapid consumption should trigger investigation before the entire budget is exhausted. Teams can use explicit policies to prioritize reliability work or pause risky changes when the budget is depleted. Review targets with business owners as usage and consequences change, rather than treating 100% availability as a practical default.