Delivery teams get asked for “an SLA” and produce one of two wrong things: an aspirational number picked in a meeting (indefensible the first bad week) or a copy of the CDN vendor’s SLA (which measures their edge, not your users). A defensible SLO is built the other way around: indicators users would recognize, targets derived from your own measured baseline, and an error budget wired to decisions — so the number does work instead of decorating a slide.
SLO, SLA, SLI: the working distinctions
Three terms, kept straight because they assign different duties. An SLI is a measurement — the fraction of requests that succeeded, the p75 time-to-first-byte. An SLO is your internal target for an SLI — what your team commits to and manages against. An SLA is a contract with consequences — what your vendor (or you, to your customers) promises with credits attached. The load-bearing distinction: your CDN’s SLA covers its infrastructure availability under its measurement rules and exclusions — it can be fully met in a month your users found miserable, because your origin, DNS, configuration and token bugs are all yours. Your SLO must therefore measure the composed, user-facing outcome, with the vendor’s SLA as one input you hold them to separately (that enforcement path is claiming SLA credits).
Choose SLIs users would recognize
Three or four SLIs cover delivery; more dilutes attention. Availability, defined as good-request ratio: successful responses over valid requests, measured from RUM plus external synthetics — never from the CDN’s own dashboard alone, for the reasons the outage playbook rehearses (the patient does not take its own pulse). Latency, as a percentile with a threshold: “p75 TTFB under X ms” or, closer to users, a page-level metric — measured per the attribution discipline in measuring TTFB so edge and origin contributions stay distinguishable. For media estates, the QoE pair — startup and rebuffer ratio — from the QoE guide, which is this method applied to video. Each SLI gets a written specification: exact metric, measurement source, valid-event definition (does a bot request count? a client abort?), and window — because every future dispute about “did we meet it” is actually a dispute about an unwritten definition.
Set targets from baselines, not aspirations
The defensible target comes from your own history: measure each SLI over a trailing quarter, look at the distribution of bad weeks (not the average — the SLO is a promise about bad weeks), and set the target at what the current estate achieves in all but its worst episodes — then tighten only alongside funded work that would move the baseline. A worked shape: if good-request ratio ran 99.95% median with two incidents dipping monthly figures to 99.87%, a 99.9% monthly SLO is defensible today; 99.99% is a wish that the first incident converts into learned helplessness — and a team that stops believing its SLO has a decoration, not a target. Resist round-number gravity and nine-counting machismo; each extra nine multiplies cost (multi-CDN, origin redundancy, on-call depth — the scorecard’s spending, justified by SLO arithmetic rather than fear). The target’s honest derivation is also its defence: when leadership asks for another nine, the baseline data turns the conversation into “here is what that nine costs,” which is the conversation worth having.
Error budgets: making the SLO do work
An SLO earns its keep through the error budget: the allowed unreliability (100% minus target) treated as a spendable quantity per window — a 99.9% monthly availability SLO grants roughly 43 minutes of full badness, or proportionally more partial badness. Wire it to decisions and it changes behaviour: budget healthy → ship freely, run the risky migration, spend some budget on the chaos drill; budget burning fast → alert on burn rate (fast-burn pages someone now; slow-burn opens a ticket) so the budget protects itself; budget exhausted → pre-agreed consequences — feature pushes pause in favour of reliability work, the deferred fix gets scheduled, the postmortem happens with teeth. The pre-agreement is everything: negotiate the consequences with product leadership in peacetime, because an error-budget policy invented mid-incident is just an argument with graphs.
Review, defend, and the vendor conversation
SLOs are living instruments. Quarterly, review each one against three questions: did it fire meaningfully (an SLO never threatened is set too loose; one perpetually breached is set too hopeful or the estate needs the funded work); did users’ actual complaints correlate with its breaches (the calibration check — an SLO green through a week of complaints is measuring the wrong thing); and did its budget actually gate any decision (if not, fix the wiring, not the number). Fold the results into the annual review, where SLO attainment becomes the year’s reliability narrative. And carry the SLO into vendor management: your internal targets, decomposed, tell you what you need from each provider — which turns the QBR from a slideshow into a negotiation about the specific reliability your promises depend on, with your own measurements as the evidence. A target your team can defend, in the end, is one with a paper trail: measured baseline, written spec, wired budget, quarterly calibration — four artifacts, none optional.