SLIs and SLOs: valid events, good outcomes and measurement boundaries
Define an SLI from valid and good events, choose an SLO window and expose measurement blind spots. Work through an availability-and-latency objective with explicit arithmetic.
TL;DR: An SLI measures a defined user outcome; an SLO sets its target over a stated window. Specify the event population, the success condition and where measurement happens before choosing a percentage.
Write the contract in a sentence
For an illustrative checkout API: “Over a rolling 28-day window, at least 99.9% of valid purchase attempts complete successfully within 800 milliseconds as observed at the service boundary.” Every phrase constrains the measurement. Define what makes an attempt valid, how cancellation and retries are handled, and what happens when telemetry is absent.
The example target and threshold are teaching inputs, not recommended defaults for every business. Choose them from user expectations, dependency behavior and the cost of improving reliability. Google's SLO implementation guidance describes user-focused indicators and stakeholder agreement.
A service-level agreement can attach contractual consequences to a service promise. An internal SLO is an engineering target and does not automatically become an SLA. Keep those terms distinct when describing customer obligations.
The numerator must belong to the denominator
For an event-based SLI, compute good events divided by valid events. If good means successful within the latency threshold, slow successful responses are bad under this combined indicator. A separate availability SLI could classify them differently.
Imagine 100,000 valid requests in a window. Of these, 99,850 succeed within the threshold, 100 succeed slowly and 50 fail. The combined SLI is 99.85%. Against a 99.9% objective, the allowed bad-event budget is 100, but 150 events were bad. The service has consumed 150% of that budget under the stated definition.
Do not add the 100 slow requests to a separate failure total unless the populations are known to be disjoint. Overlapping categories can count the same request twice. Preserve event classification rules in the metric definition and tests.
Choose a measurement point that sees the failure
A handler counter cannot count a request that never reaches the handler. A proxy can observe some ingress failures but may miss DNS or client connectivity problems. A client-side signal sees more of the user path while introducing sampling, privacy and delivery considerations.
Use complementary measurement where needed, and state which boundary owns the objective. A service can meet its internal API SLO while the user-facing journey fails elsewhere. That is a coverage gap to address, not a reason to relabel missing requests as successful.
| Measurement choice | Useful coverage | Blind spot to document |
|---|---|---|
| Handler metric | Application result and internal timing | Requests rejected before execution |
| Edge or proxy metric | Routing and upstream response outcomes | Failures before reaching the edge |
| Client telemetry | User-observed journey | Sampling and telemetry delivery loss |
| Synthetic probe | Controlled path and low-traffic detection | Does not represent all real user requests |
Metrics, logs and traces provide different evidence during diagnosis. The SLI should remain a stable contract rather than changing to whichever dashboard looks healthiest during an incident.
Exclusions need an owner
Exclude malformed input only when it is truly outside the promised valid population. An application bug that generates malformed requests for legitimate users can still be a product failure. Blanket exclusion of every 4xx response can hide authentication or rate-limit incidents caused by the service.
Also decide whether requests from an internal load test belong in the production objective. Keep them identifiable without introducing unbounded metric labels. Version the SLI definition and record changes so a better-looking chart does not silently reflect a narrower denominator.
For no traffic, the ratio may be undefined. Missing telemetry is another state entirely. Alert on measurement health and use appropriate synthetic evidence rather than treating every empty series as perfect availability.
Turn the target into a decision
An error-budget policy defines what the team does when reliability falls behind. Multi-window burn-rate alerts help identify urgent consumption. Both depend on this page's event definition being correct.
Does 99.9% mean the same downtime for every SLO? No. A request-based objective budgets bad events; a time-based objective budgets bad intervals. Traffic distribution can make their conclusions differ.
Should a slow success count as good? Under an availability-only SLI it might. Under the combined success-and-latency contract above it does not. State the definition before calculating the result.