SLO Definition

"We should have five nines" is a number picked because it sounds impressive, not because anyone measured what users actually need or what the system can actually deliver without heroics. A Service Level Objective only has value if it's derived from real user tolerance and real system behavior — otherwise it's just a more precise-sounding version of the same unfalsifiable "be reliable" instruction, and nobody will actually gate a decision on it when it matters.

This is why SLO definition is its own discipline, distinct from the broader observability practice it depends on — see observability for the signals underneath, but the number itself is a negotiated business artifact, not just a query result.

The entire value of an SLO is that it turns a subjective argument into a shared, pre-agreed number that both the "ship faster" and "slow down and fix reliability" sides accept in advance.

An SLO you wouldn't actually enforce with a release freeze isn't a real SLO — it's a vibe with a percentage sign on it.

1. Pick SLIs that measure what the user actually experiences

A Service Level Indicator is the raw measurement the SLO is built on, and the single biggest mistake is picking one because it's easy to measure rather than because it reflects the user's experience. Server-side "did we return a 200" is easy to measure and can be true while the user's request actually failed client-side, timed out, or was slow enough that they gave up.

• Prefer SLIs measured as close to the user as possible — successful page loads under a latency threshold, successful checkout completions, messages actually delivered.
• Instrument the client or an edge layer if that's what it takes, rather than settling for what server logs already happen to capture.
• A server-side 200 is a proxy, not the outcome itself — treat it as a fallback, not a first choice.

Done when: each SLI can be traced to a specific, real user-facing outcome, not just an internal system state that correlates with one.