slo-design

To design an SLO that reflects user experience, define a measurable SLI ratio with valid-request boundaries and select appropriate latency percentiles like p95 or p99 instead of averages. This ensures the SLO targets actual user impact and drives operational decisions.

An error budget policy specifies what actions teams must take when the budget is healthy, tight, or exhausted. Quantifying the SLO target into an error budget prevents teams from treating the SLO as theater by enforcing concrete operational changes during budget consumption.

Configure burn-rate alerts by designing multi-window thresholds that detect fast-burn and slow-burn failure modes. This triggers alerts during active incidents rather than after the fact, specifying exact thresholds for both rapid and gradual error budget depletion.

Latency percentiles like p95 and p99 protect against tail-latency failures that average latency masks. Using percentile-based latency SLOs ensures your service-level indicators capture the real user experience of the slowest requests, preventing misleading availability metrics.

Common SLO anti-patterns to avoid include average-latency SLOs, unrealistic targets, missing burn-rate alerts, and missing enforcement policies. Auditing for these ensures your SLO includes valid-request boundaries, rolling windows, and concrete error-budget behavior.

Yes, you can audit existing SLOs for availability versus quality by reviewing the SLI definition, measurement window, and error-budget policy. The audit checks whether latency percentile selection, rolling windows, and burn-rate alert thresholds align with real user experience and operational needs.