A Service Level Objective is a reliability target for a service, expressed as a percentage, latency bound, or throughput floor that users can depend on.
A Service Level Objective is a measurable reliability goal such as 99.9% availability, 200ms p95 latency, or 1000 requests per second. SLOs are chosen from service level indicators and enforced with error budgets.
That target is the decision-making boundary for operations and product teams. When the service is within its error budget, features ship quickly. When the budget is exhausted, the team focuses on reliability work. Without an SLO, every incident is subjective and every feature decision is a negotiation without data.
Think of it like this. Think of a restaurant promising table turnover within 30 minutes during dinner. The 30-minute target is the SLO; missed nights trigger operational fixes.
Teams define SLIs from telemetry, set SLOs as user-facing targets, and derive error budgets as the allowed failure rate. Alerting, change management, and incident response use the budget as a trigger. When the budget is near exhaustion, releases may slow or freeze.
"Higher availability is always better." Each nine costs disproportionately more engineering and reduces deployment speed. "SLOs are only for infrastructure." Application-level latency and correctness also benefit. "One SLO fits all services." Critical services need tighter SLOs than internal tools.
Creates clear reliability targets and shared language between teams, but choosing targets requires business judgment and buy-in. Overly strict SLOs create brittle cultures; loose SLOs provide little protection.