What is SLA Management?
SLA management is how you define, measure and report the service levels you promise customers. Learn SLA vs SLO vs SLI and the uptime math.
What is SLA management?
SLA management is the work of defining, measuring and reporting the service levels you have promised to customers. A service level agreement (SLA) is a contract that attaches consequences, such as service credits, to missing agreed targets like availability or response time. Managing it means writing measurable targets, instrumenting them, alerting before you breach, reporting attainment and handling credits.
SLI, SLO and SLA: the difference
The Google SRE book defines the three terms this way, and the distinction decides who owns what:
- SLI (service level indicator): a carefully defined quantitative measure of some aspect of the service, for example the share of requests that return successfully.
- SLO (service level objective): a target value or range for an SLI, for example 99.9% of requests succeed over 28 days.
- SLA (service level agreement): a contract with users that includes the consequences of meeting or missing the SLOs it contains. If there is no explicit consequence, you are almost certainly looking at an SLO.
The SRE book also notes that SLAs are tied to business and product decisions, and that running an internal SLO stricter than the public one leaves room to fix chronic problems before users notice. See reliability engineering for the wider practice.
What uptime percentages mean in time
An availability target only becomes concrete once you convert it to allowed downtime. The figures below are plain arithmetic: (1 minus the target) multiplied by the length of the window, using a 7-day week, a 30-day month and a 365-day year.
| Availability target | Per 30-day month | Per week | Per 365-day year |
|---|---|---|---|
| 99% | 7 h 12 min | 1 h 41 min | 3 d 15 h 36 min |
| 99.5% | 3 h 36 min | 50 min | 1 d 19 h 48 min |
| 99.9% | 43 min 12 s | 10 min 5 s | 8 h 45 min 36 s |
| 99.95% | 21 min 36 s | 5 min 2 s | 4 h 22 min 48 s |
| 99.99% | 4 min 19 s | 1 min | 52 min 34 s |
Check which window the contract uses. A calendar month of 31 days allows more downtime than one of 28, and 99.99% leaves about four minutes a month, which a single slow deploy can use up.
How SLA management works
- Write measurable terms. Name the scope (which endpoints or features), the measurement window, how a failed request is counted, and the exclusions, such as scheduled maintenance announced in advance.
- Measure the SLI from outside. Measure what a customer experiences, not what your server believes. External checks from several locations are harder to dispute than internal logs alone.
- Set a tighter internal SLO. If the SLA promises 99.5% per month, an internal SLO of 99.9% leaves about 2 hours 53 minutes of monthly headroom (172.8 minutes in a 30-day month) before the contract is at risk.
- Alert on the SLO, not the SLA. By the time the SLA is breached, the customer has already felt it.
- Report attainment. Publish the monthly number automatically, for example on a status page, so nobody has to argue about it.
- Handle breaches. Calculate credits from the contract schedule, tell the customer and run a review. Incident communication during the outage is part of the SLA experience.
Example
A SaaS company promises 99.5% monthly availability for its API. It runs an internal SLO of 99.9%. In a 30-day month the SLO allows 43 minutes of downtime and the SLA allows 3 hours 36 minutes. A bad deploy causes 52 minutes of errors: the SLO is missed, so the team starts an incident review, but the SLA is still met and no credit is owed. Without the internal SLO, nobody would have looked until the contract line was crossed.
Common mistakes
- Promising an SLA with no matching SLO or measurement, so attainment is argued from memory.
- Choosing a number from a table, such as five nines, instead of what the architecture can deliver.
- Measuring availability with a check from a single location, which cannot tell a regional problem from a global one.
- Counting only full outages and ignoring slow responses that customers experience as failures.
- Leaving exclusions vague, so every incident becomes a dispute.
SLA management with testing and monitoring
Monitoring produces the SLI. API monitoring checks your endpoints on a schedule and records failures and response times. LoadFocus API monitoring runs checks across 25 cloud regions, alerts through email, Slack, Microsoft Teams and other channels, and shows availability over a chosen period. The free plan checks every 5 minutes and includes one status page, and SLA reports against a target are available on paid plans.
Testing shows whether the target is realistic. You cannot defend a latency promise at peak traffic without load testing and capacity testing. For the monitoring side of the practice, read monitoring best practices for DevOps and developers.
FAQ: SLA Management
What is the difference between SLA, SLO and SLI?
An SLI is a measurement, an SLO is a target for that measurement, and an SLA is a contract that attaches consequences to missing the target. Teams usually run SLOs internally and promise a looser SLA externally.
How much downtime does 99.9% allow?
About 43 minutes in a 30-day month and about 8 hours 46 minutes in a 365-day year. Each additional nine cuts the allowance by a factor of ten.
What happens when an SLA is breached?
It depends on the contract. The common remedy is a service credit calculated from a schedule in the agreement. Read your own contract for the exact terms, claim process and exclusions.
Should the SLO be stricter than the SLA?
Yes. A stricter internal SLO gives you a warning before the contract is at risk and room to fix problems before customers feel them.
Who owns SLA management?
Several teams. Engineering owns measurement and the architecture, product and customer success own the contract and its wording, and finance handles credits.
Related terms
Related LoadFocus Tools
Put this concept into practice with LoadFocus, the same platform that powers everything you just read about.