Reliability Is a Feature: How to Spec SLOs

To spec an SLO, pick one Service Level Indicator that reflects a real user journey, set the target from your last 28-90 days of production data rather than a round aspirational number, define a fixed measurement window, and write down who owns the error budget when the target is missed. That combination — SLI, target, window, owner — is the whole contract. Everything else is implementation detail.

Quick answer: An SLO is a target on a Service Level Indicator — e.g., 99.9% of checkout requests complete under 300ms — measured over a rolling window like 28 days. Derive the number from historical performance, not from hope, and name the exact request paths it covers.

SLI, SLO, and SLA: The Three Terms PMs Keep Blurring

An SLI is the metric you actually measure, like p99 latency or error rate. An SLO is the internal target you set on that metric, like "99.9% of requests under 300ms." An SLA is the external, often contractual promise — usually a looser subset of your SLOs — with financial penalties attached. Mixing these up is exactly why "reliable" stays a vibe instead of a spec.

Most infra PMs inherit the vocabulary from Google's foundational Site Reliability Engineering book (Ben Treynor Sloss and the SRE team), which introduced SLIs, SLOs, and error budgets as a discipline rather than jargon. The follow-up SRE Workbook is more tactical and is where most of this article's method comes from.

Here's the distinction in one table:

Term	What it measures	Audience	Example
`SLI` (indicator)	The raw, measured behavior of the system	Engineering, SRE	p99 latency = 240ms this week
`SLO` (objective)	An internal target set on that indicator	Product, eng leadership	99.9% of requests < 300ms, rolling 28 days
`SLA` (agreement)	A contractual promise, usually looser, with penalties	Legal, sales, customers	99.5% uptime or a service credit

Three things follow from this hierarchy:

You can have an SLI without an SLO — you're just watching a number with no target attached.
You can't have a defensible SLA without an underlying SLO — otherwise the contract is a guess.
Your SLO should always be stricter than your SLA. The gap is your buffer against noisy neighbors, bad deploys, and one genuinely bad day.

If you're new to the seat entirely, our infra PM role complete guide covers where reliability work sits alongside platform strategy, tooling decisions, and stakeholder management — this article is the deep dive on just the SLO piece.

Why User-Journey SLIs Beat Raw Infrastructure Metrics

Anchor your SLI to what a user is trying to do — "can they finish checkout" — not to what a server is doing. Infrastructure metrics like CPU utilization, queue depth, or pod restart count can look perfectly healthy while real users sit through timeouts, because those metrics describe the system's internals, not its output.

This is the core lesson from the RED method (Rate, Errors, Duration), popularized in SRE circles as a counterpart to the older infra-facing USE method (Utilization, Saturation, Errors). RED starts from traffic through a service boundary; USE starts from the resource. Both matter to engineers. Only one maps to what your customer actually experiences.

A quick gut-check for any candidate SLI: would a customer notice if this number got worse, without you telling them?

Good SLI: percentage of checkout attempts that complete successfully within 300ms.
Bad SLI: average CPU utilization across the checkout fleet.
Good SLI: percentage of search queries returning results within 500ms.
Bad SLI: number of Kubernetes pod restarts per hour.
Good SLI: percentage of login attempts that succeed on the first try.
Bad SLI: database connection pool size.

The infra metrics aren't useless — they're diagnostic. They tell engineering why an SLO is degrading. But they're the wrong thing to put a target on, because a healthy-looking dashboard full of green infra metrics has shipped plenty of bad user experiences.

Approach	What it measures	What it hides
Infra-centric metric (CPU, memory, pod count)	System resource state	Whether the user's request actually succeeded or was fast
User-journey SLI (request success + latency at the API boundary)	What the customer experienced	Root cause — still needs infra metrics for diagnosis

Marketplace PMs face a sharper version of this problem: a single "the platform is up" metric hides that buyers and sellers can have completely different reliability experiences on the same infrastructure. Our marketplace PM role complete guide walks through spec'ing SLIs separately for each side of a two-sided journey.

Setting a Target From Data, Not From Hope

Set your target from the last 28-90 days of production performance, not from a round aspirational number like "99.99%, obviously." Pull your actual distribution, find where user complaints or support tickets start climbing, and set the SLO just above your current healthy baseline — tight enough to matter, loose enough to hit without engineering heroics.

The instinct to reach for more nines is understandable and almost always wrong on the first pass. Each additional nine of reliability costs disproportionately more engineering effort than the one before it — a point Treynor Sloss makes explicitly in the SRE book: 100% reliability is the wrong target for virtually any system, because the marginal cost of the last 0.01% usually dwarfs its marginal value to users.

A five-step process for deriving the number

Pull 60-90 days of raw data for the exact endpoint or journey — not an aggregate across your whole API surface.
Plot the full distribution, not just the average. Look at p50, p90, p95, and p99 side by side; averages hide the tail where users actually suffer.
Overlay known incidents and support-ticket spikes on the same timeline to see where performance degradation correlates with real user pain.
Set the target near, but not exactly at, your current 95th-percentile "good day" — this gives you a target that's achievable without a rewrite, but still catches regressions.
Get an engineering sign-off that the number is achievable under normal operating conditions, not just during a quiet week.

Latency thresholds aren't arbitrary either. Jakob Nielsen's long-running usability research at the Nielsen Norman Group established that responses under roughly 0.1 seconds feel instantaneous, under about 1 second keep a user's flow of thought unbroken, and beyond about 10 seconds the user's attention has left the task. That's a useful sanity check when a proposed SLO target sounds arbitrary — ask what perceptual bucket it falls into.

Once the target is set, the gap between 100% and your SLO becomes your error budget — the amount of "acceptable failure" you're allowed to spend on risky deploys, migrations, or experiments before you have to slow down and stabilize. That budget is also the mechanism for turning reliability into an actual roadmap input rather than an ops-only concern; our error-budget-driven roadmap guide covers how to use budget burn-down as a real prioritization signal alongside feature work.

A Worked Example: Spec'ing the Checkout API SLO

For a checkout API, a defensible SLO reads: 99.9% of POST /v1/checkout requests return within 300ms, measured over a rolling 28-day window, timed server-side at the load balancer, excluding announced maintenance. Every clause in that sentence exists to close off a specific ambiguity that would otherwise turn into a Slack argument during an incident.

Here's the spec written out the way it should appear in a PRD or reliability doc:

Field	Value
SLI	% of `POST /v1/checkout` requests with server-side latency < 300ms
Target	99.9%
Window	Rolling 28 days
Measurement point	Load balancer access logs / APM histogram (e.g., a `p99` metric in Datadog or a Prometheus histogram)
Exclusions	Planned maintenance announced 72+ hours in advance
Error budget	0.1% of requests in the window
Owner	Checkout squad EM, with the infra PM as escalation point
Burn-rate alert	Page on-call if budget consumption implies exhaustion within 6 hours
Consequence	Feature launches on checkout freeze once 50% of the 28-day budget is spent in any rolling 7 days

The error budget is worth making concrete rather than abstract. If checkout serves roughly 2 million requests across that 28-day window, a 0.1% budget means about 2,000 requests are allowed to land over 300ms before the team is out of budget — a number engineering can watch tick down in real time, instead of an abstract percentage on a slide.

Notice what this spec deliberately does not say: it doesn't say "the checkout service should be fast." It doesn't say "as fast as possible." Vague scope is the single most common reason SLOs get renegotiated mid-incident — nobody agreed in advance what "the service" even meant.

The SLO Spec Checklist: What Good Looks Like

A good SLO spec states the exact scope, the number, the window, the exclusions, the budget, and the owner — in writing, before the first incident tests it. If any of those six are missing, the SLO will get relitigated the moment it's inconvenient, which defeats the point of writing it down.

Use this as a pre-publish checklist:

How the spec shifts by domain

The shape of a good SLO spec doesn't change, but what belongs in it does:

Fintech PMs often need SLOs that map directly to payment-processor SLAs and regulatory expectations, where a missed target can mean real settlement delays rather than just annoyed users — see our fintech PM role complete guide for how compliance changes the reliability conversation.
Security PMs frequently spec SLOs around detection and response latency (time-to-patch, time-to-triage) rather than pure uptime — our security PM role complete guide covers that adjacent discipline.
Integrations PMs own SLOs for dependencies they don't fully control, which means the spec has to state what happens when a third-party API breaches its own SLA; our integrations PM role complete guide goes deeper on managing reliability you can't directly engineer.

From Spec to Roadmap: Where Prodinja Fits

An SLO is only as defensible as the scope behind it, and "the checkout service" is not a scope — it's a guess that different stakeholders will fill in differently. Turning that vague phrase into a concrete artifact is a modeling problem as much as a measurement one.

Key Takeaways

An SLI is a measurement, an SLO is a target on that measurement, and an SLA is the external contract — keep the three distinct or "reliable" stays a vibe.
Choose SLIs from the user's journey (checkout completes, search returns, login succeeds), not from infrastructure internals like CPU or pod counts.
Derive your target from 60-90 days of real production data and its full percentile distribution, not from a round number that sounds impressive.
Every additional "nine" of reliability costs disproportionately more engineering effort — set the loosest target that still protects the user experience.
A worked spec (like the checkout API's POST /v1/checkout, 99.9% under 300ms, rolling 28 days) should state SLI, target, window, exclusions, error budget, and owner explicitly.
The error budget — the gap between 100% and your SLO — is what turns reliability from an ops-only concern into a real roadmap input.
Naming exact endpoints, rather than "the service," is the single biggest predictor of whether an SLO survives its first incident intact.

Frequently Asked Questions

What's the actual difference between an SLO and an SLA?

An SLO is an internal target your team sets and monitors day to day; an SLA is the external, contractual version of a subset of your SLOs, usually looser, with financial penalties attached if missed. You can have SLOs with no SLA at all — most internal APIs do — but you shouldn't have an SLA without a stricter internal SLO backing it up.

How do I choose the right SLI for a new API with no history yet?

Start with the RED method — Rate, Errors, Duration — measured at the API boundary the caller actually experiences, not at an internal component. For a brand-new endpoint, launch with a wide, deliberately loose target for the first measurement window, then tighten it once you have real traffic data to set the number from.

What SLO target should I start with if I have no historical data at all?

Use an industry-typical starting point like 99.5% for a non-critical internal service or 99.9% for a customer-facing critical path, but treat it explicitly as provisional. Commit in writing to revisiting the number after your first full measurement window (28-90 days) using the five-step process above, rather than treating the starting guess as final.

How often should SLOs be reviewed once they're set?

Quarterly is a reasonable default cadence, with an off-cycle review triggered by any major traffic shift, architecture change, or incident that reveals the target no longer reflects reality. Google's SRE Workbook frames SLOs as living documents precisely because traffic patterns and system architecture both drift, so a target set a year ago may now be either too loose or unreachable.

Do I need an SLO for every API, or just the critical ones?

Just the ones tied to a real user journey or a genuine business dependency — spreading SLOs across every endpoint dilutes attention and burns engineering time on monitoring low-stakes paths. Prioritize the handful of journeys where a miss is visible to a customer or triggers a support ticket, and let everything else stay a monitored SLI without a formal target.