Start with the user's successful outcome
A service-level indicator measures a behavior that matters to users, such as a valid request completing within an agreed latency threshold. A service-level objective sets the target for that indicator over a defined window. An error budget expresses the tolerated shortfall. These concepts become useful when they guide concrete operational decisions.
A contractual SLA is a separate agreement with its own scope, exclusions and remedies. Publishing an internal SLO does not automatically create an SLA. This guide focuses on a software team's alerting and release policy rather than promising an arbitrary availability percentage.
Setup: define eligible events and failure
Write the SLI numerator, denominator, latency boundary, measurement point and window. Decide how to classify rejected input, dependency failures, partial responses and maintenance. Preserve the user's perspective: a successful internal health probe does not prove that a customer completed the intended workflow.
Review traffic volume and data quality before choosing alert thresholds. Google SRE describes burn rate as the speed of error-budget consumption relative to the SLO and discusses alert designs using different windows. Treat its examples as design guidance, not universal settings for a service with different traffic or consequences.
Illustrative incident: an uptime chart stays green during checkout failure
An illustrative application serves its homepage successfully while an important transaction endpoint fails. Infrastructure availability looks healthy, but eligible user operations consume the error budget rapidly. This teaching example is not a real client incident or a fabricated availability result.
Trace the user operation through the selected measurement point. Compare request success, business completion and latency. If the indicator counts only a proxy's successful response code, it may miss an application-level failure encoded inside that response.
Troubleshooting: review the signal before the threshold
| Observation | Evidence | Investigation |
|---|---|---|
| Users fail while the SLI is healthy | Eligibility and success definition | Is the indicator measuring the useful outcome? |
| Alerts fire on tiny traffic samples | Event counts and window size | Is low-volume behavior handled deliberately? |
| Fast damage is detected too late | Burn rate and alert windows | Does detection fit the consequence? |
| Alerts repeat without action | Ownership and runbook | Is there a meaningful response policy? |
Do not improve the chart by excluding inconvenient failures after an incident. Changes to eligibility need a reviewed rationale and versioned definition. Otherwise comparisons across releases lose meaning.
Corrective action through an explicit policy
Connect budget consumption to actions such as investigating a candidate release, pausing risky changes or prioritizing reliability work. Define who may approve an exception and what evidence is required. An automated alert can inform the decision; it should not silently rewrite contractual commitments or bypass incident ownership.
Use short and longer observation windows where appropriate to distinguish sustained damage from noise. Keep deployment revision and dependency evidence available so operators can correlate impact without assuming that every alert was caused by the latest release. Include a rollback criterion that considers data and schema compatibility as well as application binaries.
Verification, policy review and SOP
Replay or simulate known failures against the indicator and alert logic. Confirm routing, acknowledgment and the action described by the runbook. Test a latency-only failure and a low-volume period, not just a total outage. Verify that the release gate uses current trustworthy data and reports missing measurements explicitly.
The SOP should name SLI ownership, objective review cadence, error-budget calculation, alert recipients, exception authority and post-incident follow-up. Review targets against user needs and observed capability before making external promises. Report actual measurements with their window and scope; never invent uptime results to strengthen marketing copy.
See observability and monitoring and DevOps automation.
Technical reference
Google SRE alerting on SLOs, reviewed 19 October 2026. Follow documentation matching the installed product version.