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 may spend before you breach the objective.
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 ship that. The first transient failure uses up the whole budget.
- 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 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 hit its traffic targets and also protect the latency, availability, and error-rate objectives the service is expected to meet.
