Home / Glossary / SLA (Service Level Agreement)
Tech & ITSLA (Service Level Agreement)
By Sitraka Forler · Lecturer, Durham Business SchoolUpdated 3 October 2026 About this site
A contract promising a level of service, such as uptime, usually with penalties if missed.
An SLA is the promise made to customers, usually backed by service credits (money off a future bill) if it is broken. Engineers aim for a stricter internal service level objective (SLO), tracked with a service level indicator (SLI) such as the share of successful requests. Always check the period: 99.9% uptime allows 43.2 minutes of downtime in a 30-day month, but 8.76 hours over a 365-day year.
The intuition
An SLA is a promise with a price attached. A provider tells a customer how available, or how fast, a service will be over a stated period, and agrees to give something back, usually a service credit, if it falls short. Behind that promise sit two quieter ideas. The service level indicator, or SLI, is the measurement itself: the share of requests that succeeded, or the share of minutes in which the service answered. The service level objective, or SLO, is the target the engineering team sets for that measurement. Think of driving: the SLI is the speedometer, the SLA is the posted limit with a fine for breaking it, and the SLO is the stricter speed you hold yourself to, so that one bad stretch of road does not cost you money. Availability targets are quoted in nines: 99.9% is three nines, 99.99% is four.
What makes the three terms useful together is the error budget. Define the SLI as good events divided by valid events over a window, set the SLO, and one minus the SLO is the share of failure you are allowed. A service that handles 10,000,000 requests in 30 days against a 99.9% SLO may fail 10,000,000 × 0.001 = 10,000 of them; a time-based target of 99.9% over the same 30 days allows 43.2 minutes down. Every outage, bad release or failed migration spends from that budget. The practice, popularised by Google's Site Reliability Engineering book in 2016, is to agree in advance what happens as the budget runs down: while some remains, the team ships features and takes risks; once it is spent, releases pause and the work turns to reliability until enough budget has returned. The old argument between speed and stability becomes a number both sides read the same way.
Most SLA surprises live at the edges. First, the window: a percentage means little until you know whether it is measured per calendar month, per rolling 30 days or per year, because a yearly allowance can be spent in one long outage that would breach the same percentage measured per month. Second, dependencies: services called in series multiply their availabilities, so an application that needs two components, each at 99.9% and failing independently, can expect about 0.999 × 0.999 = 0.998001, or 99.8001%, before its own bugs are counted. Third, the remedy: service credits are usually a percentage of the monthly fee for the affected service, typically have to be claimed and are capped, and are often the only remedy the contract allows, so they rarely cover what an outage costs you. Practitioners keep the internal SLO tighter than the SLA, measure as close to the user as they can, and read the exclusions, such as scheduled maintenance, before quoting a number.
Example
minutes_in_month = 30 * 24 * 60 # 43,200 minutes
for target in (0.999, 0.9995, 0.9999):
allowed = minutes_in_month * (1 - target)
print(f"{target:.2%} uptime: {allowed:.2f} min of downtime allowed")
# 99.90% uptime: 43.20 min of downtime allowed
# 99.95% uptime: 21.60 min of downtime allowed
# 99.99% uptime: 4.32 min of downtime allowedTurning 99%, 99.9%, 99.95% and 99.99% into allowed downtime per 30-day month and per year
- Count the minutes in each window. A 30-day month has 30 × 24 × 60 = 43,200 minutes and a 365-day year has 365 × 24 × 60 = 525,600 minutes, which is 525,600 / 60 = 8,760 hours. Allowed downtime is the window multiplied by the unavailability, 1 - target.
- 99%, two nines: the unavailability is 1 - 0.99 = 0.01. Per month, 43,200 × 0.01 = 432 minutes, and 432 / 60 = 7.2 hours, which is 7 hours 12 minutes (0.2 × 60 = 12). Per year, 525,600 × 0.01 = 5,256 minutes, and 5,256 / 60 = 87.6 hours; 87.6 - 72 = 15.6 hours over 3 whole days, and 0.6 × 60 = 36, so 3 days 15 hours 36 minutes.
- 99.9%, three nines: the unavailability is 1 - 0.999 = 0.001. Per month, 43,200 × 0.001 = 43.2 minutes, which is 43 minutes 12 seconds (0.2 × 60 = 12). Per year, 525,600 × 0.001 = 525.6 minutes, and 525.6 / 60 = 8.76 hours; 0.76 × 60 = 45.6 minutes and 0.6 × 60 = 36 seconds, so 8 hours 45 minutes 36 seconds.
- 99.95%: the unavailability is 1 - 0.9995 = 0.0005. Per month, 43,200 × 0.0005 = 21.6 minutes, which is 21 minutes 36 seconds (0.6 × 60 = 36). Per year, 525,600 × 0.0005 = 262.8 minutes; 262.8 - 240 = 22.8 minutes over 4 whole hours, and 0.8 × 60 = 48, so 4 hours 22 minutes 48 seconds.
- 99.99%, four nines: the unavailability is 1 - 0.9999 = 0.0001. Per month, 43,200 × 0.0001 = 4.32 minutes, which is 4 minutes 19.2 seconds (0.32 × 60 = 19.2). Per year, 525,600 × 0.0001 = 52.56 minutes, which is 52 minutes 33.6 seconds (0.56 × 60 = 33.6).
- Read the pattern. Each extra nine divides the allowance by ten: 432 / 43.2 = 10 and 43.2 / 4.32 = 10. Moving from 99.9% to 99.95% only halves it: 43.2 / 21.6 = 2. And a 365-day year is not twelve 30-day months: at 99.9%, 12 × 43.2 = 518.4 minutes against 525.6 for the year, a gap of 525.6 - 518.4 = 7.2 minutes, which is exactly the allowance for the 365 - 360 = 5 extra days, 5 × 1,440 × 0.001 = 7.2.
- Spend a budget. A team holds a time-based 99.95% SLO under a 99.9% SLA, both measured over the same 30 days, so its error budget is 21.6 minutes. A bad release causes a 15-minute outage: 15 / 21.6 = 0.69444..., so about 69.44% of the budget is gone and 21.6 - 15 = 6.6 minutes, or 6 minutes 36 seconds, remain. The contract is still safe, with 43.2 - 15 = 28.2 minutes of headroom before the SLA is breached and credits can be claimed, which is exactly what the gap between SLO and SLA is for.
Convert every availability percentage into minutes over its stated window before you promise or accept it: 99.9% and 99.99% sound almost the same, but over a 30-day month one permits 43.2 minutes of downtime and the other only 4.32.
Common pitfalls
- Quoting a percentage without its window. At 99.9% the familiar 43.2 minutes holds only for a 30-day month: a 28-day February gives 28 × 1,440 × 0.001 = 40.32 minutes and a 31-day month gives 31 × 1,440 × 0.001 = 44.64 minutes. A yearly target is looser still in practice, because all 525.6 of its minutes can be spent in a single outage.
- Setting the SLO equal to the SLA. With no margin between the internal target and the contract, the first sign of trouble is a customer claiming a credit. Keep the SLO tighter, for example 99.95% under a 99.9% SLA over a 30-day month, so the team exhausts its 21.6-minute budget with 43.2 - 21.6 = 21.6 minutes of contractual headroom still left.
- Promising more than your dependencies can deliver. Components called in series multiply their availabilities, so an application that needs a database and an external API, each at 99.9% and failing independently, starts from 0.999 × 0.999 = 0.998001. Over a 30-day month that is 43,200 × (1 - 0.998001) = 43,200 × 0.001999 = 86.3568 minutes of expected downtime, almost twice the 43.2 minutes a 99.9% SLA of your own would permit.
- Measuring the SLI in the wrong place. A check that only asks whether the server process is running can read 100% while users see errors from an expired certificate, a DNS fault or a broken load balancer. Define the SLI as good events over valid events, measure it as close to the user as practical, and agree which requests count as valid before arguing about the number.
- Treating service credits as insurance. Credits are usually a percentage of the affected service's monthly fee: for example, a 10% credit on a €2,000 bill is 2,000 × 0.10 = €200, whatever the outage cost your trading desk. If an outage would cost more than the credit, pay for resilience, such as a second region or a second provider, rather than for a stronger-sounding SLA.
Frequently asked questions
What is an SLA?
An SLA, or service level agreement, is a contract, or a section of one, in which a provider commits to a measurable level of service, such as monthly availability or response time, over a stated period. It also says what happens if the commitment is missed, usually a service credit against a future bill, and what is excluded, such as scheduled maintenance. Agreements also exist inside a single organisation, and ITIL calls one between an IT service provider and another part of the same organisation, which supports the service the provider delivers to customers, an operational level agreement (OLA).
What does 99.9% uptime mean?
It means the service may be unavailable for 0.1% of the measurement window. Over a 30-day month that is 43,200 × 0.001 = 43.2 minutes, or 43 minutes 12 seconds; over a 365-day year it is 525,600 × 0.001 = 525.6 minutes, or 8 hours 45 minutes 36 seconds; per day it is 1,440 × 0.001 = 1.44 minutes, or 1 minute 26.4 seconds. Which of those applies depends on the window written into the agreement.
What is the difference between an SLA, an SLO and an SLI?
The SLI is the measurement, for example the share of requests that returned successfully in under 300 milliseconds. The SLO is the target set for that measurement, such as 99.95% over a rolling 30 days, and it is usually an engineering commitment with no penalty attached, even when a team chooses to publish it. The SLA is the external contract that promises a level of service to customers and attaches consequences, and it is normally set looser than the SLO so the team has a margin before a miss costs money.
What is an error budget?
An error budget is the amount of failure an SLO allows: one minus the target, applied to the window. A 99.9% SLO over 10,000,000 requests allows 10,000 failed requests, and a time-based 99.95% SLO over 30 days allows 21.6 minutes of downtime. Teams agree in advance what happens as it is spent, typically slowing or freezing releases once it runs out, so decisions about risk follow the number rather than the loudest voice.
What is a service credit in an SLA?
A service credit is the compensation a provider gives when it misses the SLA, normally a percentage of the monthly fee for the affected service, applied to a future bill rather than paid in cash. The percentage usually rises in tiers as measured availability falls further below the promise. Credits generally have to be claimed within a deadline, are capped, and are often the sole remedy, so they compensate for the bill, not for the business the outage cost you.
Why not promise 100% uptime?
Because no service can guarantee it: hardware fails, networks drop packets, every dependency has downtime of its own and releases sometimes go wrong, and past a point users cannot even notice the gain, because their own phones and connections fail more often than the service does. A 100% target also leaves an error budget of zero, so the first failed request is a breach and every change becomes a risk nobody is allowed to take. Providers choose a target they can meet with a margin, remembering that each extra nine divides the allowed downtime by ten, from 43.2 minutes in a 30-day month at 99.9% to 4.32 minutes at 99.99%.