SLOs for high-performance systems
· 8 min
It's common for a team to set a performance target, "p99 under 200ms", without clearly distinguishing what's actually being measured, promised, or budgeted. That confusion between similar-sounding terms is the root of most SLOs nobody can actually act on.
SLI, SLO, and SLA aren't the same thing
SLI is the actual measured indicator, request latency, for instance. SLO is the internal target for that indicator, 99% of requests under 200ms over 30 days. SLA is the external, often contractual promise, with a formal consequence for breach. Mixing the three up leads to either overly conservative SLAs, or SLOs nobody can really use to decide anything day to day.
Error budget: the metric that decides, not just describes
An error budget is simply 100% minus the SLO, the amount of failure already accepted upfront. That turns a static target into an operational tool: with budget left, the team can take on more release risk; once the budget is spent, the priority shifts to stability until it recovers.
Why the wrong percentile is worse than no SLO
Picking the right percentile matters: p50 hides exactly the tail problems that disproportionately affect a real slice of users, while p999 can be so strict that it ends up dominated by noise and outliers unrelated to any real degradation. The right choice depends on request volume and how much a single slow request actually costs the business.
Defining an SLO that survives the first incident
A good SLO is one you can occasionally violate without it becoming an emergency, is tied to a real user-facing consequence, and gets revisited with real traffic data instead of being picked once and forgotten.