SLO (Service Level Objectives)

A startup's engineering team set an implicit goal of zero downtime. Every outage, even a 30-second blip, triggered a war room, a postmortem, and a week of remediation work. Feature development ground to a halt. The team spent 80% of their time on reliability improvements and 20% shipping product.

The irony? Their users were perfectly happy with the service's actual reliability. The occasional 30-second hiccup didn't even register. But without a defined target, every imperfection felt like a failure.

An SLO (Service Level Objective) is the target value for an SLI, the specific number your team agrees is "good enough." Not perfect. Good enough. It says "we aim for 99.9% availability over a rolling 30-day window" and by doing so, it gives the team permission to accept 0.1% unavailability. 43 minutes per month, as normal and expected.

SLOs transform reliability from an emotional topic ("we had an outage, that's terrible") into an engineering decision ("we've used 15 of our 43 allowed minutes this month, we should be careful with risky deployments").

An SLO is an SLI + a target + a time window:

How to choose the target number:

1. Start with current performance. If your service currently achieves 99.95%, don't set the SLO at 99.999%. Set it slightly below current performance, maybe 99.9%, to give yourself a realistic error budget.

2. Consider user expectations. A consumer app used daily needs higher availability than an internal admin tool used twice a week. A payment system needs near-perfect correctness. A recommendation engine can tolerate occasional bad results.

3. Consider the cost. Each additional nine roughly costs 10x more engineering effort. Pick the level that matches business value.

4. Tighten over time. Start conservative, then tighten as your team matures. It's much better to consistently beat a 99.9% SLO than to constantly miss a 99.99% one.