Service Level Objective (SLO): A Measurable Promise
An SLO is a precise, measurable promise about your service's performance, like "99.9% of requests will succeed." It's the internal engineering target that backs up a customer-facing SLA. The footgun is setting a 100% SLO, which leaves no room for failure.
WHY IT EXISTS To move beyond vague promises like "the service should be reliable." SLOs provide a specific, quantitative target for engineering teams to build and operate against, creating a shared understanding of what "good enough" means and aligning business and technical stakeholders.
THE MENTAL MODEL Think of an SLO as a promise you make to your users, but written as a number for your engineers. It's the target on the wall. The SLI (Service Level Indicator) is the metric you use to measure where your shots land. The SLA (Service Level Agreement) is the business contract that might specify consequences, like refunds, if you miss the target too often.
HOW IT WORKS You start by choosing a critical user journey, like "checking out a shopping cart." Then you pick a metric to measure it—the SLI, such as the percentage of successful checkout API calls. Finally, you set a target for that metric over a time window. For example: "99.95% of checkout requests over a rolling 30-day period will complete successfully in under 3 seconds." This target is the SLO. The remaining 0.05% is your "error budget"—the amount of failure you can tolerate before violating your objective.
WHEN TO USE IT Use SLOs to make data-driven decisions about priorities. They provide a clear signal for when to focus on shipping new features versus when to pause and improve stability. If you have consumed your error budget for the month, all work might shift to reliability until the service is back within its SLO.
WHEN NOT TO USE IT Avoid creating SLOs for every single metric. This creates noise and alert fatigue. Focus on the few key indicators that directly represent the user's experience of availability, latency, or correctness. An SLO on an internal database's CPU usage is less useful than one on user-facing API response time.
ONE CANONICAL EXAMPLE A media streaming service wants to ensure a good playback experience. They define an SLI as "playback availability," measured by the percentage of times a user clicks play and the video starts successfully. They set an SLO of 99.9% availability over a 28-day window. If availability drops to 99.8%, they have violated their SLO and must prioritize fixing the underlying issues.
Read the original → en.wikipedia.org
Get five bites like this every day.
Tezvyn delivers a daily feed of 60-second tech bites with quizzes to lock in what you learn.