ServiceLevelObjectives
title: Service-Level Objectives type: technique created: 2026-05-21 last_updated: 2026-05-21 related: ["radar/techniques/DockerSecuritySelfHosting"] sources: ["https://thenewstack.io/translating-failures-into-service-level-objectives/"] radar_quadrant: Techniques radar_ring: Assess radar_position: inner
A technique for defining and measuring system reliability by expressing targets as quantifiable thresholds on Service-Level Indicators (SLIs), derived from observed failure patterns rather than aspirational uptime figures.
An SLO is a target percentage applied to an SLI — a measurable signal of user-facing system behaviour. Common SLIs: request latency, error rate, throughput, and availability. An SLO might read: "99.9% of homepage requests return within 200ms over a rolling 28-day window."
The critical shift the technique introduces is directionality: SLOs are set by analysing failure modes first, then translating them into quantifiable targets — not the reverse. Starting from failures ensures SLOs capture what actually causes user pain rather than what sounds acceptable in a planning meeting.
The workflow described in the source article follows four steps:
- Identify failure categories. Review incidents, support tickets, and postmortems. Cluster failures into types: latency, errors, data consistency, throughput.
- Select SLIs for each category. Map each failure type to a measurable signal. Latency failures → p99 response time SLI. Error failures → error rate SLI.
- Set thresholds from historical data. Use observed good-state performance as the floor. Set SLO targets slightly above the observed baseline — not at 100%.
- Define error budgets. The gap between 100% and the SLO target is the error budget. Budget exhaustion triggers escalation or feature-freeze.
The error budget makes SLOs operational. When the budget is healthy, development teams can move fast. When the budget is depleted, reliability work takes priority over feature work. This converts an abstract reliability goal into a concrete negotiation between development velocity and system stability.
Service-Level Objectives sit in the Assess ring of the Techniques quadrant. SLOs are a mature SRE practice introduced at Google and documented widely via the SRE Book (2016), and by 2023 they are standard practice in organisations running production services with measurable user traffic. That maturity is third-party evidence, not first-person use: SLOs have not been defined or tracked in the user's own service, and the Adopt or Trial ring requires that, so the practice stays at Assess. The "translate failures first" framing is a refinement that improves SLO quality by grounding targets in observed failure data rather than arbitrary uptime targets. No novel tooling required — SLOs are a methodology, implemented with existing monitoring infrastructure (Prometheus, Datadog, Grafana). The gate to Trial is at least one SLO defined and tracked against a real service.
