SLI, SLO, SLA
Three acronyms, one letter apart, and most teams use them interchangeably. The sloppiness has consequences: an engineering target wanders into a customer contract, or a contract number ends up deciding who gets paged at 02:40. Harborline's checkout acquires all three in this chapter, so the definitions come first.
An SLI — service level indicator — is a measurement. An SLO — service level objective — is an internal target for that measurement. An SLA — service level agreement — is an external contract with money attached when the target is missed. Keeping them apart is the difference between engineering decisions and legal ones.
SLI: The Measurement
A Service Level Indicator is a number you can compute from telemetry you already collect, almost always a ratio of good events to valid events over a window. Harborline's checkout has two obvious candidates: the fraction of checkout requests that returned something other than a 5xx, and the fraction that completed in under 500 ms. Both are ratios, both read on a 0-to-1 scale, and both can be answered by a PromQL query against the counters from Chapter 3 and the histogram from Chapter 5.
The queryability is the definition. If you cannot compute it from data you are collecting today, it is not an SLI — it is a wish. Topic 50 builds Harborline's two checkout SLIs concretely; everything else in this chapter stands on them.
SLO: The Internal Target
A Service Level Objective binds an SLI to a target and a window: checkout availability 99.9% over a rolling 28 days, and 95% of checkout requests under 500 ms. All three parts are mandatory. A target without a window is meaningless — 99.9% over an hour permits a 3.6-second blip, 99.9% over 28 days permits 40 minutes of total downtime, and those describe entirely different services.
Engineering and product own the SLO together, and it is deliberately stricter than anything promised to a customer. Missing it triggers a conversation — about the roadmap, the next deploy, where the budget went — not a payout. Mara and the bookings team set these two numbers in a meeting, not a config file, because the target encodes a business judgment about how much unreliability ferry passengers will actually tolerate.
SLA: The External Contract
A Service Level Agreement is a promise to customers with defined penalties — service credits, refunds — when it is breached. Business and legal write it, and its numbers are deliberately looser than the SLO, precisely so the internal target breaks first and gives the team room to detect and react before money moves.
Harborline already lives on the consuming side of one: the card processor publishes a 99.95% SLA. That number is a contract, not a measurement. It tells you what the processor pays out against, and nothing about how the service actually behaves this month.
Ownership and Timescales
Engineering and product own the SLIs and SLOs and can revise them quarterly as the service and its users change. The SLA belongs to the business and moves on contract timescales: annual renewals, negotiated amendments. When a salesperson asks "can we promise 99.99%?", the measured SLO history is the answer — and if the SLO says 99.9%, the honest contract number is lower still. Going from 99.9% to 99.99% shrinks the allowed downtime by a factor of 10, from about 40 minutes to about 4 minutes per 28 days, and a signature does not make that happen.
The Gap Is the Point
Harborline's internal checkout SLO is 99.9%. A customer-facing SLA, if the business ever writes one, would sit at 99.5% or lower. The gap between the two numbers is not padding — it is the buffer in which engineering detects a problem, reacts, and fixes it before a breach becomes a credit. Set them equal and the first time engineering learns about a contract breach is when the customer files for a refund.
SLI — the measured ratio itself: non-5xx checkout requests divided by all checkout requests. Use the term when the conversation is about queries and data.
SLO — the internal target on that SLI: 99.9% over 28 days. Use it when the conversation is about alerting, error budgets, and roadmap decisions.
SLA — the external, penalty-bearing contract built on the same measurement. Use it only when customers and lawyers are in the room. One SLI can serve both an SLO and an SLA; the SLO is always the stricter number.
- Setting the internal SLO equal to the contractual SLA — there is no stricter internal tripwire to break first, so the first time engineering learns about a breach is when a customer files for credits.
- Calling an unmeasured aspiration an SLO ("we target four nines") with no SLI behind it — a target with no query is unfalsifiable, and unfalsifiable targets change no decisions.
- Letting a salesperson put 99.99% into a contract when the measured history shows 99.9% — that factor-of-10 gap in allowed downtime (4 minutes versus 40 per 28 days) becomes a recurring service-credit bill.
- Defining the SLI on a metric customers never experience, like
app-01CPU — a host can run at 95% CPU while every checkout succeeds, and sit idle while checkout is down; the contract-relevant signal is the request outcome. - Writing a number without a window — "99.9% availability" means nothing until you say over what period, because 99.9% over an hour and 99.9% over a quarter permit wildly different incidents.
- Define every SLO as SLI + target + window in one sentence — "99.9% of checkout requests non-5xx over a rolling 28 days" — and store it next to the recording rules that compute it.
- Keep the SLO strictly tighter than any SLA, and treat the gap between them as the incident-response buffer the team gets to consume before penalties start.
- Route "what can we promise the customer" questions to the measured SLO history in Grafana, not to intuition — 12 months of SLI data settles the argument.
- Review SLO targets quarterly with product in the room, because the target encodes a business judgment about user tolerance, not a purely technical constant.
Knowledge Check
Which statement sorts the three terms correctly?
- The SLA is the measurement, the SLO the target, the SLI the customer contract
- SLI = measurement, SLO = internal target, SLA = external contract
- All three are customer-facing promises that differ only in strictness
- The SLO is the legal contract and the SLA is the engineering target behind it
Why must the internal SLO be stricter than any external SLA?
- Because stricter targets are cheaper to compute in Prometheus
- Because auditors require a documented difference between the two numbers for compliance sign-off
- So the SLO breaks first, leaving room to react before the contract is breached
- So that any SLO miss automatically triggers customer service credits
A salesperson asks whether Harborline can promise 99.99% checkout availability in a contract. What should answer that question?
- The card processor's published 99.95% SLA
- CPU and disk utilization trends on app-01 and app-02
- The engineering lead's gut feeling about system stability
- The measured SLO attainment history
Why is "99.9% availability" meaningless without a window?
- The same percentage permits radically different incidents over different periods
- Prometheus cannot compute a ratio without a fixed window parameter
- Windows are only needed in SLAs, where lawyers demand precise dates in the penalty clause
- Because 99.9% is too lax a target to mean anything in production
You got correct