How many SLOs should a service have?

Two or three per service. Typically one availability SLO, one latency SLO, and optionally one quality SLO (e.g., freshness or correctness). More than that and no one can hold them all in mind; less and you're missing dimensions users care about.

What window should we measure over?

Rolling 30-day is the default. Shorter windows (1 day, 7 days) react faster but are noisier and can trigger false alarms. Longer windows are more stable but slower to detect degradation. Some mature teams run both a 30-day SLO for budget decisions and a 1-hour burn-rate alert for detection.

Should SLOs apply to internal services?

Yes, especially for internal platforms with multiple consumers. An internal service without an SLO becomes 'whatever it happens to deliver,' which makes it impossible for consuming teams to set their own SLOs. Every service with more than one consumer benefits from an explicit SLO.

Service Level Objectives (SLOs): Setting Targets Your Team

A service level objective is a target for a specific reliability characteristic of a service — latency, availability.

Service Level Objectives: The Reliability Budget That Ends the Reliability Debates

A service level objective (SLO) is a target value for a service reliability metric — for example, '99.9% of API requests complete successfully over a rolling 30-day window' or '95% of checkout requests return in under 500ms.' SLOs are the internal-facing companion to SLAs (which are customer-facing legal commitments) and are the frame around which Google's SRE practice was built. The point of an SLO is not to hit 100%; it is to explicitly declare how much unreliability the business can absorb, and use the remainder — the error budget — to move faster.

SLI, SLO, SLA — the distinctions

SLI (Service Level Indicator) — the actual measurement, e.g., 'ratio of successful requests to total requests over 5-minute windows.' SLO — the target for that SLI, e.g., '99.9% over 30 days.' SLA — the contractual promise to customers, typically looser than the SLO to leave headroom, e.g., '99.5%, with credits if breached.' Confusing these leads to reliability theater; a team that only tracks the SLA has no early warning before customer credits get triggered.

Pick SLIs users would actually care about

The best SLI approximates 'is a user having a good experience.' For a web app: successful HTTP responses over total, and request latency at some percentile. For a batch job: percentage of jobs completing within the target window. For a data pipeline: freshness of the downstream data. Avoid SLIs that are easy to measure but not user-visible — 'CPU utilization under 80%' is not an SLI; users don't care about your CPU. The best signals come from the client side (real user monitoring) when practical, not just server-side aggregates.

The error budget mechanic

If your SLO is 99.9%, your error budget is 0.1% — about 43 minutes of unavailability per 30-day window. The budget is spendable: risky deploys, new feature rollouts, and infrastructure changes all consume budget. When budget is healthy, the team can move fast; when budget is exhausted, the team pauses feature work and prioritizes reliability. This turns 'engineering wants to refactor vs. product wants to ship' from a values fight into a data-driven decision that both sides can accept.

Setting the target honestly

The right SLO target is not 'as high as possible' — it's the lowest number that keeps customers happy, because every additional nine of reliability costs exponentially more to achieve and slows the team down. Start by measuring current performance for a few weeks, then set the SLO slightly stricter than current reality if you want to drive improvement, or match reality if the current level is acceptable. Aspirational SLOs you're constantly missing generate cynicism; achievable ones with real teeth generate behavior change.

What SLOs don't cover

SLOs measure aggregate behavior over windows; they miss individual bad experiences and correlated failures. A 99.9% SLO comfortably tolerates a single customer having 100% error rate — the aggregate stays green while that specific customer churns. Complement SLOs with alerting on customer-specific error spikes and with post-incident reviews that examine correlated failures. SLOs are the floor of your reliability practice, not the ceiling.

Frequently asked questions

How many SLOs should a service have?: Two or three per service. Typically one availability SLO, one latency SLO, and optionally one quality SLO (e.g., freshness or correctness). More than that and no one can hold them all in mind; less and you're missing dimensions users care about.
What window should we measure over?: Rolling 30-day is the default. Shorter windows (1 day, 7 days) react faster but are noisier and can trigger false alarms. Longer windows are more stable but slower to detect degradation. Some mature teams run both a 30-day SLO for budget decisions and a 1-hour burn-rate alert for detection.
Should SLOs apply to internal services?: Yes, especially for internal platforms with multiple consumers. An internal service without an SLO becomes 'whatever it happens to deliver,' which makes it impossible for consuming teams to set their own SLOs. Every service with more than one consumer benefits from an explicit SLO.

Related fundraising guides (40)

Investor directory · Fundraising library · Articles A–Z · Company funding database