Free — no signup required

SLO (Service Level Objective): The Goal

2 min read

Setting the Target

An SLO (Service Level Objective) is the target value or range for your SLI. It is the internal goal your engineering team commits to in order to keep users happy.

If the SLI is the measurement ("we are currently at 99.5% success"), the SLO is the line in the sand ("our goal is to stay above 99%"). The SLO defines what "good enough" looks like, quantitatively.

Anatomy of a Well-Formed SLO

A complete SLO has four components:

  1. The SLI being measured — what are we tracking?
  2. The target threshold — what value must be met?
  3. The measurement window — over what time period?
  4. The population — which requests or users does this apply to?

Example: "99.9% of HTTP GET requests to /api/profile that originate from authenticated users will return a 200 OK response in under 200ms, measured over a rolling 30-day window."

This is far more actionable than "the service should be fast and reliable."

Choosing an SLO

Setting an SLO is a business and product decision, not just a technical one. The right SLO depends on what your users actually need.

Step 1: Measure your current baseline. What are you achieving today? If you're currently at 99.7% availability, setting an SLO of 99.99% is aspirational but not grounded in reality. Start with your current performance and tighten over time.

Step 2: Understand user tolerance. Talk to product owners and look at support tickets. At what error rate do users start complaining? At what latency do they abandon the page? This is your "happiness threshold." Your SLO should sit just above it.

Step 3: Consider the service tier. A free photo-sharing app needs less reliability than a banking payment API. A batch data pipeline can tolerate more latency than a real-time trading system. Match the SLO to the business criticality.

Step 4: Don't pick 100%. We already established why. Even 99.999% is often unjustifiable for most services.

The SLO Review Cycle

SLOs are not set-and-forget. Revisit them quarterly:
- If you are consistently exceeding your SLO with budget to spare, tighten it — you may be over-investing in reliability at the cost of feature velocity.
- If you are consistently burning through your budget, either improve reliability or have an honest conversation about whether the SLO is realistic.

This is one of 18 chapters

Every chapter is free — Kubernetes, Terraform, SRE, distributed systems, and more — with fast daily review built in.

Sign up free