slo-implementation

Define an SLI as a PromQL ratio of good events to total events, then create recording rules that compute the ratio over a rolling window such as 28 days. Add a compliance rule comparing the SLI against your target, for example 99.9% availability.

Error budget equals 1 minus the SLO target, so a 99.9% availability SLO allows 0.1% errors, roughly 43.2 minutes of downtime per month. Track remaining budget as (SLI minus target) divided by (1 minus target).

Multi-window burn rate alerting combines a short window and a long window in one alert condition to catch real budget consumption while filtering noise. A fast-burn alert might require both 1-hour and 5-minute burn rates above 14.4x before paging.

Choose targets based on user expectations, business requirements, current performance, and the cost of additional reliability. Avoid 100% targets since they leave no error budget; 99.9% is a common starting point for user-facing APIs.

A typical error budget policy freezes non-critical changes when remaining budget drops to 10% and enforces a full feature freeze at 0%. At 50% remaining, teams should consider postponing risky changes.