The Beginner's Guide to Service Level Objectives (SLOs)

Every team has an informal sense of what "reliable enough" means. SLOs make it formal, measurable, and actionable.

Without SLOs, reliability discussions are subjective: "I think we've been doing okay." With SLOs, they're data-driven: "We're at 99.94% against our 99.9% target, with 12 minutes of error budget remaining this month."

SLO Terminology Made Simple

SLI (Service Level Indicator)

The actual measurement. "Our homepage availability this month was 99.97%."

SLO (Service Level Objective)

The target. "We aim for 99.95% homepage availability."

SLA (Service Level Agreement)

The contractual promise with consequences. "We guarantee 99.9% availability. If we breach this, we issue service credits."

Think of it this way: SLIs are what you measure, SLOs are what you aim for, and SLAs are what you promise.

Choosing What to Measure

Good SLOs are based on what users actually experience. Focus on:

Availability

What percentage of requests succeed?

• Good SLI: Successful HTTP responses / total HTTP responses
• Bad SLI: Server CPU below 80% (users don't care about CPU)

Latency

How fast are responses?

• Good SLI: P95 response time < 500ms
• Bad SLI: Average response time (averages hide outliers)

Quality

Are responses correct?

• Good SLI: Responses with complete data / total responses
• Bad SLI: No errors in the log (some errors are invisible to users)

Setting Your First SLOs

Step 1: Measure Your Baseline

Before setting targets, measure where you are. Run monitoring for 2-4 weeks and collect:

• Current availability percentage
• Current P50, P95, P99 response times
• Current error rates

Step 2: Choose Realistic Targets

Don't aim for perfection on day one. Set targets slightly above your current performance:

• If you're at 99.8%, target 99.9%
• If your P95 is 800ms, target 1 second, then iterate down

Step 3: Define Error Budgets

The error budget is the amount of unreliability your SLO allows:

• 99.9% availability = 0.1% error budget = 43.2 minutes/month
• 99.95% availability = 0.05% error budget = 21.6 minutes/month

As long as you're within your error budget, you can ship features freely. When the budget is running low, prioritize reliability.

Step 4: Set Up Monitoring

Track your SLOs in real time:

• Dashboard showing current SLI vs SLO
• Error budget remaining (both absolute minutes and percentage)
• Error budget burn rate (are you consuming budget faster than expected?)

Step 5: Define Responses

What happens when error budget gets low?

• 75% consumed: Warning to the team, review recent changes
• 90% consumed: Freeze non-critical deployments
• 100% consumed: All engineering effort shifts to reliability

SLOs for Common Services

Web Application

SLI	SLO
Availability	99.95%
Homepage P95 latency	< 1 second
API P95 latency	< 500ms
Error rate	< 0.1%

Payment Processing

SLI	SLO
Transaction success rate	99.99%
Payment P95 latency	< 3 seconds
Webhook delivery rate	99.9%

Internal API

SLI	SLO
Availability	99.9%
P95 latency	< 200ms
Error rate	< 0.5%

Common SLO Mistakes

Setting Targets Too High

99.99% sounds great but allows only 4 minutes of downtime per month. If you can't actually achieve it, you'll permanently be in "budget exhausted" mode and the SLO becomes meaningless.

Too Many SLOs

Start with 2-3 SLOs for your most critical user journeys. You can always add more later.

Not Acting on Budget Burns

An SLO without consequences is just a number on a dashboard. The team must actually change behavior when the budget is running low.

Measuring the Wrong Things

SLOs should measure user experience, not infrastructure metrics. "Database CPU < 80%" is not an SLO. "Search results return within 500ms" is.

Getting Started Today

1. Pick your most important user journey
2. Measure its current availability and latency for 2 weeks
3. Set a target slightly above your current performance
4. Calculate the error budget
5. Set up monitoring and dashboard
6. Review weekly as a team

SLOs transform reliability from a vague aspiration into a concrete engineering practice. Start simple, measure often, and iterate.