What Is a Service Level Objective (SLO)? | Vantage
Service Level Objective A Service Level Objective (SLO) is a target value or range for a Service Level Indicator (SLI), the metric that measures a specific aspect of service reliability. Common SLIs include availability (percentage of successful requests), latency (percentage of requests served under a threshold), and error rate (percentage of failed requests). An SLO specifies the target: 99.9% of requests will complete in under 500ms or availability will be at least 99.5% over a rolling 30-day window. The gap between 100% and the SLO target is the error budget — the allowed unreliability that teams spend on deployments, experiments, and change.
Why service level objective matters
SLOs resolve the fundamental tension between reliability and velocity. Without explicit reliability targets, operations teams push for zero risk (no changes) while engineering teams push for maximum velocity (constant change). SLOs make reliability a quantified, shared goal: when the error budget is healthy, teams deploy fast. When it is burned, teams slow down and invest in reliability. This is a data-driven conversation rather than a values conflict.
How it works
Define the SLI (what to measure), set the SLO (the target), calculate the error budget (allowed unreliability), measure continuously via your observability stack, alert when the error budget burn rate is high (not just when the budget is exhausted), and review SLO compliance in weekly or monthly reliability reviews. Service Level Agreements (SLAs) are the contractual, customer-facing commitments derived from SLOs — SLOs are internal targets set conservatively below SLA commitments.
Common mistakes
Setting 100% SLOs — 100% availability is impossible and leaves no error budget for any change
Too many SLOs — three to five per service is sufficient; measuring everything means nothing is prioritized
Not connecting error budget to deployment decisions — the error budget is only useful if it gates velocity
SLOs without SLIs — a reliability target without a measured indicator is aspiration, not a commitment
Ignoring the long tail — a 99th percentile latency SLO matters more to user experience than mean latency
Related terms
How Vantage relates
Vantage allows PMs to include SLO requirements in PRD context. Non-functional requirements like the API must respond to 99% of requests within 200ms are extracted into requirements that generate corresponding tickets — ensuring SLO work is tracked and resourced alongside feature work rather than remaining as informal engineering expectations.