Mental model#
A service level objective is a target for an SLI over a time window. It expresses the reliability needed for a user journey and creates room for imperfection; it is not automatically a contractual SLA or a promise of zero failure.
Mechanism and state flow#
- Select a user-centered SLI and a window long enough to guide decisions.
- Choose a target from product need, dependency capability, recovery time, and the cost of higher reliability.
- Define how the window moves, how delayed data is handled, and which traffic classes are separate.
- Use budget consumption to prioritize release, reliability, and capacity work.
- Revisit a target when user behavior, architecture, or business criticality changes.
Concrete example#
Why 99.99% is a design decision
For 30 days, 99.9% permits roughly 43 minutes of bad time if measured by time, while 99.99% permits roughly 4 minutes. A dependency with longer failover cannot support the tighter target without architectural change.
Architecture consequence: Agree on the target before promising multi-region failover, extra replicas, or operational staffing whose cost may not serve the product.
Scaling and operational trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Tighter objective | Small outages create material user or business harm. | Redundancy, testing, operational coverage, and slower change cost more. |
| Separate journey objectives | Read, write, and administrative paths have different criticality. | More indicators and policies must remain understandable. |
| One service-wide objective | The service is simple and user paths share failure behavior. | A healthy aggregate can hide one critical journey. |
Failure diagnosis#
- Failure
- A team sets a 100% objective and treats every error as an emergency.
- Impact
- Risky work is hidden, releases stall, and operators chase failures the architecture cannot economically eliminate.
- Detection
- Budget is always zero and policy cannot distinguish harmful regression from expected imperfection.
- Mitigation
- Choose a product-backed target below perfection and document the budget response.
- Trade-off
- The product explicitly accepts a bounded amount of failure.
Checklist exercise#
Work the scenario before revealing your answer
- Choose one SLI and compare the operational consequence of two targets.
- List the dependencies and recovery time that constrain the target.
- Define separate objectives only where user impact or ownership truly differs.
Level calibration#
| Level | Useful evidence |
|---|---|
| SDE I–II | Define a user-centered SLI and explain the target window. |
| Senior | Connect dependency budgets, failure recovery, and alerting to the objective. |
| Staff | Negotiate objectives across product and platform boundaries and make the reliability cost visible. |
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- Why this target and window?
- What architecture would a tighter objective require?
- How do low-traffic services avoid misleading windows?
- How does this objective influence release decisions?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Service level objectivesGoogle SRE
- Monitoring distributed systemsGoogle SRE
Sources reviewed 2026-09-04. Product-specific controls and threat assumptions still require current verification.