SRE in Practice #1 Designing SLIs and SLOs: What to Measure and How Many Nines to Promise

In SRE vs DevOps we established that the heart of SRE is “contracting reliability in numbers,” and in SLI, SLO, SLA we sorted out the three terms. This series answers the next question: so how do you actually do it? The first part covers designing SLIs and SLOs — the starting point of everything — walking through exactly the places where people who know the concepts still get stuck when handed the task “define our service’s SLOs.”

Start from user journeys, not from the dashboard #

The most common mistake is picking SLIs from the list of metrics you already collect (CPU, memory, thread counts). CPU at 90% means nothing to a user. What users experience is “does checkout work” and “do search results come back fast.”

So design starts by listing critical user journeys (CUJs). For an e-commerce site:

1. Product search → results displayed
2. Product page view
3. Add to cart → payment completed

For each journey, ask “if this breaks, does the user feel the service is broken?” and rank accordingly. Checkout is unconditionally top-tier; the recently-viewed widget is not. Build SLOs for the top journeys first — just two or three to start. Build dozens on day one and you get a document nobody reads.

A good SLI is a ratio: good events / total events #

With journeys chosen, define the indicator — the SLI. Practice has converged on one shape: the proportion of good events out of total events.

The ratio form wins for three reasons: it normalizes to 0〜100% and connects directly to the SLO, it compares across traffic volumes, and error budget arithmetic follows naturally.

One caution on latency: “average response time 300ms” is not an SLI. Averages hide a minority of very slow requests. Define it as threshold + ratio — “99% of requests complete within 300ms” — and the slow tail stays visible. Managing by percentiles (p99) is the same concern in another notation.

Where to measure: the trade-offs of measurement points #

The same SLI takes different values depending on where it is measured.

• Server (application): easy to implement, but misses failures that never reached the server (DNS, network, load balancer outages). Reads better than reality.
• Load balancer: captures server-down cases at low implementation cost — the best-balanced default for most teams.
• Client (RUM): closest to what users actually experienced, but user devices and networks mix in noise you cannot control.

The principle: measure as close to the user as possible, within the range you control. For most teams the answer is load balancer logs, with client-side measurement added later as a supplementary signal.

The SLO target: start from current performance, not aspiration #

Deciding “how many nines” in a meeting room is backwards. The correct order:

1. Measure current performance. If the real SLI over the last four weeks is 99.94%, that is the starting point.
2. Check against user expectations. If users are content at today’s performance, an SLO near it (99.9%) is reasonable. If they are not, raise the target and plan the engineering to close the gap.
3. Check the cost. Every additional nine multiplies cost. 99.99% allows four minutes of downtime per month — and a human paged into action needs several minutes just to respond. From that level, automated recovery is a prerequisite, and you have to ask whether that investment is justified for this service.

One sentence to remember: an SLO is an operating promise, not a marketing number. A 99.9% you keep beats a 99.99% you cannot, for both the team and the users. And 100% is the wrong target for any service — the moment 100% is the goal, every change becomes the enemy and deploys stop.

The window: rolling four weeks is the default #

An SLO is defined with a period: “99.9% over a rolling 28-day window.”

• A rolling window always looks at the last N days. Incidents age out of the window gradually, which matches operational intuition. Four weeks (28 days) is the de facto standard — it contains exactly four of each weekday, making it steadier than 30 days.
• A calendar window resets by month or quarter. It suits contracts (SLAs) and reporting, but has the awkward property that budget snaps back the moment the window resets.

Many teams run both: rolling 28 days for internal operations, calendar quarters for external reporting.

What goes in the SLO specification #

The design ends as a one-page document. Minimum contents:

• SLI definition: the exact definition of good and total events, the measurement point (which logs, which metrics), and exclusions (health-check traffic, bots)
• SLO target and window: 99.9% / rolling 28 days
• Owner and stakeholders: who moves when this SLO breaks
• Link to the error budget policy: what was agreed to happen when the budget runs out (next part’s topic)
• Review cadence: at least annually, or when the service’s nature changes

Writing down exclusions matters most. Debating “does planned maintenance count?” or “do client errors (4xx) belong in the denominator?” for the first time in the middle of an incident is already too late.

Summary #

• SLIs start from critical user journeys, not metric inventories. Begin with SLOs for just the top two or three journeys.
• A good SLI is a good/total ratio. Define latency as “proportion within threshold,” never as an average.
• Measure close to the user, within what you control. The practical default is the load balancer.
• Set SLO targets from current performance, checked against user expectations and cost. 100% is not a target.
• Rolling 28 days is the default window; record definitions, exclusions, and owners in a document.
• Next part: operating the error budget that falls out of this SLO — the policy and the burn rate.