The three layers
- SLI — Service Level Indicator. A measurement: 'the proportion of successful requests over 5 minutes', 'p99 latency'. SLIs are facts about the system.
- SLO — Service Level Objective. A target on an SLI: '99.9% of requests succeed, measured monthly'. SLOs are internal commitments that guide engineering.
- SLA — Service Level Agreement. A contract with consequences: 'if monthly uptime falls below 99.9%, customers get service credits'. SLAs are promises to customers, usually with money attached.
The ordering rule
Set SLOs inside your SLAs: if the SLA promises 99.9%, the internal SLO should be stricter (say 99.95%) so you get alerted while there's still margin. An SLO equal to the SLA means the first warning arrives with the breach.
And never sign an SLA you can't measure — without the SLI instrumentation, the agreement is a wish.
Worked example (illustrative).
Illustrative: SLI = successful checkout requests ÷ total checkout requests (5-min window). SLO = 99.95% monthly. SLA = 99.9% monthly with credits below it. The 0.05% gap is the early-warning buffer.
What small teams actually need
Start with one SLI per critical user path, one SLO per SLI, and no SLA until customers demand one. Error budgets — the allowed failure room inside an SLO — then become the decision tool: budget remaining means ship features; budget exhausted means reliability work wins.
Assumptions and limits
- Concepts follow the standard SRE framing; no vendor-specific claims.
- Examples are illustrative.
Common questions
Do small teams need SLAs?
Usually not at first — SLAs are customer contracts with consequences. Start with SLIs and SLOs internally; add an SLA when customers or deals require one, and set it looser than your internal SLO so you have warning margin. And never sign an SLA you can't measure — without the SLI instrumentation, the agreement is a wish.
What is an error budget?
The failure room inside an SLO — e.g., a 99.9% SLO allows 0.1% failures, which is the budget. Error budgets then become the decision tool: budget remaining means ship features; budget exhausted means reliability work wins. Spend it on feature velocity; when it's exhausted, reliability work takes priority until the budget recovers.
What makes a good SLI?
One that measures what users experience — successful requests, latency at the edge — not what servers report. A server can be 'up' while users can't check out; user-centric SLIs catch the difference. Concrete examples: the proportion of successful requests over 5 minutes, or p99 latency — measurements that are facts about the system.
Published · Updated . Availability planning guides for small web teams. Models are planning tools, not guarantees.
Sources: Google SRE Book: Service Level Objectives and the Google SRE Workbook: Implementing SLOs — the standard SRE framing this page follows. Examples are illustrative.
The next outage is a matter of when.
Be the team with the plan: a one-page runbook with named roles, severity levels, and the first-15-minutes sequence.