SLOs, SLAs and error budgets
An SLA is a promise with money attached. An SLO is the internal target you actually manage to. Confusing the two leads teams to either chase perfection they do not need or miss the reliability they promised.
Three initials get muddled constantly. Sorting them out is the difference between managing reliability deliberately and just hoping for it.
The three terms
- SLI — the indicator you measure: uptime, latency, error rate.
- SLO — the objective you set for that indicator: “99.9% of requests succeed”.
- SLA — the agreement with a customer, with consequences if the SLO is missed. See claiming service credits.
The error budget
If your SLO is 99.9%, then 0.1% is your error budget — the amount of failure you are allowed before you have broken your target. That budget is a tool: while you have it, you can take risks and ship changes; when you have spent it, you slow down and stabilise. It turns reliability from a vague wish into a number you can spend.
Higher is not always better
Every extra nine costs more — often far more — than the last. Chasing 99.99% for a service that would be fine at 99.9% burns effort users will never notice. Set the target to what the service actually needs, not to the most impressive number. See what 99.9% actually means.
Measure the thing users feel
An SLO on server uptime can be met while users have a bad time — the server is up but slow, or up but returning errors. Measure what the user experiences: successful, timely requests. See monitoring your own server.
What we commit to, and what you build on it
Our SLA covers our layer — power, network, the hardware. Your own service’s reliability is built on top of that with your architecture and your error budget. A provider’s 100%-network SLA does not make a single-server application highly available — see high availability, honestly.
Still stuck? Mail support@novogara.com — an engineer answers, at any hour. Back to the knowledge base