reliability
Service Level Objective (SLO)
SLO — a target percentage (uptime, latency p95, error rate) measured over a rolling or calendar window, with an associated error budget.
Also known as: service level objective
Definition
A Service Level Objective is a measurable target (99.9 % uptime, p95 latency < 500 ms, error rate < 0.1 %) over a rolling or calendar window. Its complement is the error budget — the amount of failure you are allowed to spend before the objective is breached.
In Maxoperf
Maxoperf uses SLO language in monitoring and release-gate workflows so teams can connect a load test to the service promise it protects. Treat SLO thresholds as product decisions first, then encode them as test criteria or monitor alerts where the workflow supports it.
Common pitfalls
- Setting 99.999 % for a service whose dependencies don’t even pretend to ship that — the budget evaporates on the first transient.
- Forgetting that planned maintenance still consumes the budget unless explicitly suppressed via a maintenance window.
FAQ
How is an SLO different from an SLA?
An SLA is the externally promised contract; an SLO is the internal target you actually engineer to (often tighter than the SLA, with a budget to spend on releases).
How should teams connect SLOs to load tests?
Use the SLO to set the release decision: a test should not only hit traffic targets, it should protect the latency, availability, and error-rate objectives the service is expected to meet.