SLO Culture
An SLO that lives only in Prometheus changes nothing. The recording rules from Topic 50 and the burn-rate ladder from Topic 52 are machinery; what turns the number into decisions is the machinery around the machinery — a monthly report the whole org reads, a written rule for what happens when the budget runs out, and the discipline to start with one SLO instead of twenty.
This closing topic is about that cultural layer, and about its two hardest sells. The first is that 100% is the wrong target — not an ambitious one, a wrong one. The second is that a single honest SLO beats twenty mediocre ones, which runs against every instinct a program rollout has.
The Monthly SLO Report
One page per SLO: the target, the attainment, the budget spent and what spent it, the trend against the previous window. It goes to engineering, product, and leadership on the same day. Topic 51's whole argument was that the budget works as negotiation currency — and currency only functions when both sides of the negotiation can see the balance. A report that circulates inside the SRE channel is telemetry without an audience: product keeps making roadmap calls without the one number that was supposed to inform them.
The Decision Rule, Written Down
Harborline's policy fits on a page. Budget exhausted: feature releases for the checkout journey pause, and the next sprint's capacity goes to reliability work until the SLI holds its target for seven consecutive days. Below 50% remaining mid-window: risky deploys need a second reviewer. That is the whole document — and its value comes from when it was written, in calm weather, signed by engineering and product before the first window ever opened.
The alternative is negotiating consequences during the incident that spent the budget, which produces whatever the loudest person in the room wants. With the rule pre-agreed, enforcement is mechanical rather than political: nobody is punishing anyone, the policy is simply executing, the way a merge freeze executes when CI goes red.
The Case Against 100%
Each added nine costs roughly ten times the engineering effort of the last — redundancy, failover drills, multi-region state — while the improvement shrinks below what users can perceive. A customer booking a ferry on a flaky phone over terminal Wi-Fi experiences last-mile failures at rates well above 0.1%; past a point, extra nines vanish into that noise. And 100% exactly forbids every deploy, every maintenance window, and every dependency failure, so the first incident turns the target into a joke and takes the SLO program's credibility down with it.
The Dependency Ceiling
Availability also has a hard ceiling that no amount of engineering moves: the things checkout must synchronously call. Two serial 99.9% dependencies already cap the caller near 99.8% — 0.999 × 0.999 — before its own code fails once. Harborline's card processor publishes a 99.95% SLA, an allowance of about 20 minutes per 28 days. A 99.99% checkout SLO would grant itself 4 minutes of budget while depending on a service allowed to be down for 20: the processor's own allowance could spend the budget five times over, leaving the bookings team accountable for a number they cannot influence. The SLO sits below the dependency ceiling, or it stops being an engineering target at all.
One SLO First
The tempting rollout is an SLO per endpoint — twenty targets, a wall of dashboards, a program launch. Twenty simultaneous SLOs produce twenty arguments about SLI definitions and zero changed decisions: each one needs its recording rules, its alert ladder, and its report maintained, no team sustains that at twenty, and the stale ones poison trust in the accurate ones.
Harborline runs checkout alone for two full 28-day windows. The first report moves a feature release behind the follow-through on the Chapter 8 connection-pool fix — the Topic 51 meeting — and that one changed decision, not a slide deck, is the argument for expansion. Search gets its SLO next, carried by evidence that the loop demonstrably works.
- Announcing a 100% availability target — it forbids all deploys, all maintenance, and all dependency failures, so the first incident makes the target a joke and the whole SLO program loses credibility with it.
- Adopting SLOs without the decision rule — the budget hits zero, product asks "so what?", nothing happens, and the org has learned that the SLO is decoration; the consequence must be agreed before it is ever needed.
- Launching fifteen SLOs in the first quarter — every one needs an SLI debate, recording rules, alerts, and a report; at fifteen, none get maintained, and the stale ones poison trust in the accurate ones.
- Keeping the SLO report inside the SRE team — product keeps making roadmap calls without the budget balance, which was the entire point; a report the decision-makers never see is telemetry without an audience.
- Copying another company's 99.99% because it appears in their engineering blog — their traffic, dependency ceilings, and revenue-per-minute are not Harborline's; a target unmoored from your own cost curve and user tolerance is either unreachable or meaningless.
- Write the error-budget policy as one page — thresholds, consequences, who arbitrates disputes — and get engineering and product sign-off before the first window opens.
- Set the SLO target below the measured ceiling of your synchronous dependencies, and revisit it whenever a dependency's published SLA changes.
- Ship the monthly report to the whole org from a Grafana dashboard anyone can open — attainment, budget spend, attribution — not from a hand-built slide deck that dies when its author changes teams.
- Run one SLO for two full 28-day windows before adding the second, and let the first roadmap decision it changes be the argument for expansion.
Knowledge Check
The checkout error budget hits zero mid-window. Under Harborline's written policy, what happens?
- The SLO target is lowered until the budget shows positive again
- Leadership convenes after the incident to decide a proportionate response case by case
- Checkout feature releases pause; sprint capacity shifts to reliability
- All deploys freeze org-wide until the 28-day window resets
Checkout synchronously calls two dependencies, each 99.9% available. What is the ceiling on checkout's own availability?
- 99.9% — a chain is as available as its weakest link
- Just under 99.8%
- 99.99%, provided every call is wrapped in retries
- About 99.95%
The card processor's SLA is 99.95%. Why would a 99.99% checkout SLO be fiction rather than ambition?
- The processor's allowance alone is five times checkout's entire budget
- Prometheus cannot measure availability to four-nines precision
- Internal SLOs are legally barred from exceeding a supplier's SLA
- Four nines is simply too expensive for a company of Harborline's size to engineer
Why does the chapter insist on one checkout SLO instead of an SLO per endpoint?
- Twenty SLOs would blow up Prometheus series cardinality
- Sloth and Pyrra only support a handful of SLOs per service
- Per-endpoint SLOs are an anti-pattern that must never be built at any scale
- Twenty at once change no decisions; one run honestly earns the rollout
You got correct