Mental model#
A service level indicator is a measured ratio or distribution representing what users experience. Define its population, good-event rule, measurement point, exclusions, and known bias before assigning a target.
Mechanism and state flow#
- Name the user journey and count the total eligible events.
- Define which events are good: successful, fast enough, fresh enough, or correct enough.
- Choose a measurement point close to the user while retaining diagnostic dimensions separately.
- Record exclusions such as invalid requests explicitly rather than silently deleting hard cases.
- Validate the indicator against real incidents and gaps in instrumentation.
Concrete example#
Checkout availability SLI
Total events are valid checkout confirmations at the edge. Good events return the documented success outcome within 1.5 seconds. Client validation failures are excluded; authenticated server failures and timeouts are not.
Architecture consequence: Measure the complete user-facing path at the boundary, then use internal metrics to diagnose which dependency caused a bad event.
Scaling and operational trade-offs#
| Option | Choose when | Cost or limit |
|---|---|---|
| Edge measurement | End-to-end user experience matters. | It may not reveal the failing internal component. |
| Server handler measurement | The service owns a well-defined internal contract. | It omits network, proxy, and client-side failures. |
| Synthetic probe | Real traffic is sparse or continuous coverage is required. | The probe may not match actual users or data. |
Failure diagnosis#
- Failure
- The SLI counts only requests that reached a healthy application instance.
- Impact
- Load-balancer, routing, and startup failures disappear from availability reporting.
- Detection
- Edge errors rise while the application-reported SLI remains healthy.
- Mitigation
- Measure at the externally meaningful boundary and reconcile edge totals with application telemetry.
- Trade-off
- Boundary measurement includes failures outside the team's direct control but inside the user journey.
Checklist exercise#
Work the scenario before revealing your answer
- Write numerator, denominator, threshold, and measurement point for one journey.
- List excluded events and defend each exclusion.
- Name one instrumentation failure that would make the indicator look healthier than users are.
Use these prompts to extend the design. The useful answer is a reasoned change, not a memorized sentence.
- What exactly is a total event?
- Where is the indicator measured?
- Does the metric include timeouts and dropped traffic?
- How would you measure correctness or freshness, not only availability?
Related practice problems
Use the manifest-backed prompts below to apply this lesson in a complete design.
- Service level objectivesGoogle SRE
- Monitoring distributed systemsGoogle SRE
Sources reviewed 2026-09-04. Product-specific controls and threat assumptions still require current verification.