reliability
Service Level Objective: A Founder’s SLO Starter Guide
A service level objective gives a product team a shared reliability target. Start with user journeys, measurable indicators, and a response rule.
TL;DR — A service level objective (SLO) is a target for a user-facing measure over a period. Start with one journey customers care about, measure its success, set a realistic target, and decide what the team will do when it misses.
A service level objective turns “the product should be reliable” into a shared operating decision. An SLO is not a contractual promise by itself. It is an internal target, measured by a service level indicator (SLI), that helps a team judge when reliability needs more attention than new feature work.
Google’s SLO chapter defines an SLO as a target value or range for a service level measured by an SLI. The useful part for founders is the user focus: choose behavior people experience, rather than a server metric that may look healthy while checkout, login, or an API call is failing.
Start with one user journey
Pick a journey that carries real customer or revenue consequence: sign in, save a record, complete checkout, receive a report, or call a public API. Define a successful event from the user’s point of view. For an account app, an SLI might be the proportion of valid sign-in attempts that complete within a chosen response threshold. For a data product, it might be the proportion of scheduled exports delivered by their agreed time.
Avoid measuring everything at once. An early SLO program with one honest signal is more useful than a dashboard full of proxies. The measure needs a denominator, a time window, a data source, and a rule for what counts as a failure. If those are unclear, the target will create arguments rather than resolve them.
Set a target and an error budget
The target is a product decision, not a universal reliability number. Higher reliability costs time, complexity, and sometimes delivery speed. The gap between the target and perfect success is the error budget: the amount of failure the team has agreed it can tolerate during the window.
Use an uptime calculator to understand the arithmetic, but do not begin with a number because another company uses it. A hypothetical target of 99.9% success over a 30-day window allows roughly 43 minutes of unsuccessful time if “availability” is the right measure; it says nothing about whether a 43-minute failure at peak billing time is acceptable. The customer journey and business context decide that.
Link an SLO to a response
An SLO without a response is a decorative metric. Define what happens as the budget burns: increase attention, pause risky releases, investigate the most common failure, or schedule a resilience improvement. Google’s error budget policy guidance shows how an agreed policy can make reliability tradeoffs less political.
Keep the response proportional. A single transient miss may need observation; repeated failures in a purchase flow may deserve an incident and a delivery change. The cost of downtime guide helps frame impact without inventing industry averages.
Review with product, not only operations
Review the SLO alongside customer feedback, support load, revenue events, and upcoming changes. An objective can be technically met while customers are still unhappy because it measures the wrong journey. Conversely, a target can be missed by low-impact events while the product remains useful. Adjust the indicator when evidence says it is misaligned; do not quietly redefine it just to make a chart green.
When a miss triggers a serious incident, capture the timeline and action items in a blameless postmortem. That completes the loop: customer experience sets the target, telemetry exposes the miss, and follow-up makes the system more dependable.
SLOs are valuable because they force an explicit choice about reliability. They give a growing team a common language for deciding when to ship, when to pause, and what customers actually need protected.
Start small and revise from evidence
Run the first objective for a full operating window, inspect missed events, and ask whether they matched customer pain. Change the indicator only with a recorded reason. This is how a young product develops reliability practice without copying a large company’s operational machinery.
Keep the initial measurement simple enough that the team can audit it during an incident. A target nobody can explain or reproduce will not improve a release decision when it matters.