SLO

Definition

An SLO, service level objective, is a target for how reliable a service should be, expressed as a measured indicator held over a time window: 99.9 percent of requests succeed over 30 days, or 95 percent of checkouts complete in under two seconds. It is a commitment you can compute.

What it means in observability

SLOs turn reliability from a vibe into a number that engineering and business can negotiate over. Perfect reliability is neither achievable nor worth its cost, so an SLO states how much imperfection is acceptable, and the error budget it implies becomes a shared currency: spend it on velocity when reliability is healthy, defend it when the budget runs low. Done well, SLOs also fix alerting, replacing noisy cause based alerts with symptom based ones that fire only when users are actually affected.

How it works in practice

The construction has three parts. Choose an SLI, the indicator that best reflects user experience, usually a ratio of good events to total events. Set the objective, the target percentage and the window it is measured over. Then operate on the error budget, alerting on burn rate, how fast the budget is being consumed, so a sudden incident and a slow leak both surface at the right urgency. Reporting closes the loop, making reliability visible in the same reviews as feature progress.

Where it gets hard

The hard part is honesty. An SLI that measures what is easy rather than what users feel produces a reassuring number and an unhappy customer base. Too many SLOs dilute attention until none of them steer anything. And the measurement is only as good as the telemetry beneath it: sampled or gappy data quietly skews the ratios that budgets and alerts are computed from.

Where Tsuga fits

Tsuga's Analytics supports the ratio and percentile queries SLIs are built from, with formulas for computing budgets and monitors for burn rate style alerting, all over complete rather than sampled telemetry.