ITIL 4 defines a service level agreement as "a documented agreement between a service provider and a customer that identifies both services required and the expected level of service." In practice, an SLA is the promise you can be held to. It names what you will deliver, how it will be measured, and what the customer gets if you miss.
That last part is what separates an SLA from everything else in this family. An objective you set for yourself is a target. An agreement with a remedy attached is a contract.
The three types of SLA
Most confusion about SLAs is really confusion about which of these three you are being asked to sign.
| Type | What it covers | Typically used for |
|---|---|---|
| Customer-based | One customer, every service they use | Enterprise contracts |
| Service-based | One service, every customer using it | Shared platforms |
| Multi-level | Layered: corporate, customer, service | Large organizations |
Customer-based agreements cover one customer across every service they consume. They are common in enterprise contracts, where the buyer wants one document rather than nine.
Service-based agreements cover one service across every customer who uses it. Shared platforms default to this, because the alternative is maintaining a different promise per tenant on the same infrastructure.
Multi-level agreements layer the two. A corporate level covers terms that apply to everyone, a customer level covers a specific account, and a service level covers a specific service. This avoids restating the same clauses in fifty documents, at the cost of a reader having to hold three documents in their head.
What goes into an SLA
Seven components. An agreement missing any of the first four is not enforceable in any useful sense.
- The services covered. Named explicitly, with anything adjacent named as excluded. Ambiguity here is where most disputes start.
- The metrics. What is measured, in what units.
- The measurement method. Who measures, from where, over what window, and using whose clock. Two parties measuring the same service from different vantage points will get different numbers, and the agreement should say whose number counts.
- The targets. The threshold each metric has to clear.
- Responsibilities on both sides. Customers have obligations too, usually around how they report problems and how quickly they respond to requests for information.
- Exclusions. Scheduled maintenance, force majeure, failures in the customer's own systems, and third-party dependencies you do not control.
- Remedies and review. What the customer gets when a target is missed, and how often the agreement is revisited.
The metrics an SLA measures
Four metrics carry most agreements. Each has a failure mode worth knowing before you commit to it.
| Metric | What it measures | The trap |
|---|---|---|
| Availability | The share of time the service is usable | "Usable" is doing a lot of work. Define it, or you will argue about it. |
| Response time | How fast you acknowledge a reported problem | Easy to hit and easy to game. Acknowledgement is not progress. |
| Resolution time | How fast you restore service | The one customers care about, and the hardest to promise honestly. |
| Error rate | The share of requests that fail | Averages hide short, total outages. Pair it with availability. |
Availability is the one most agreements lead with, and it is usually expressed in nines. The arithmetic is unforgiving, which is why the worked example below matters more than any amount of explanation. See uptime for how availability is calculated in practice.
A worked example: one month, one service
Take a payments API on a 99.9% monthly availability commitment.
A 30-day month contains 43,200 minutes. A 99.9% target allows 43.2 minutes of downtime. Not 43.2 minutes per incident. 43.2 minutes for the month, in total.
Now run a bad month. A database connection pool exhausts at 02:14 on a Tuesday. Detection takes 9 minutes because the alert routed to a channel rather than a person. The on-call engineer acknowledges 6 minutes later. Diagnosis takes 31 minutes. The fix and verification take 22 minutes.
Total: 68 minutes.
Achieved availability for the month is (43,200 − 68) ÷ 43,200 = 99.84%. The commitment was 99.9%. You are 25 minutes over budget, from a single incident, on a service that was otherwise healthy for 29 days and 22 hours.
Two things follow, and both are more useful than the number itself.
Your monthly error budget is smaller than one bad night. At 99.9%, a single incident with an ordinary coordination delay can consume the entire month's allowance. That is an argument for shortening detection and acknowledgement, not for promising more nines.
The nines you agree to are an operational commitment, not a marketing number. Moving from 99.9% to 99.99% cuts your monthly allowance from 43.2 minutes to 4.3 minutes. Almost no team can absorb a single unplanned incident inside 4.3 minutes without automated failover. Sign that number only if the architecture behind it is real.
Penalties and service credits
Most commercial SLAs settle breaches with service credits: a percentage of the fee, returned against a future invoice. Tiered structures are typical, with the credit rising as achieved availability falls.
An illustrative structure, and it is illustrative rather than a standard, because credit tiers vary widely by contract:
| Achieved monthly availability | Typical service credit |
|---|---|
| At or above the target | None |
| Below target, at or above 99.0% | 10% of the monthly fee |
| Below 99.0%, at or above 95.0% | 25% of the monthly fee |
| Below 95.0% | 50% of the monthly fee, and usually a termination right |
Three things worth knowing before you either offer or accept a credit structure.
Credits are almost never claimed automatically. Most agreements require the customer to request them inside a window, often 30 days. An unrequested credit is usually a forfeited one.
Credits rarely reflect the actual loss. A ten percent credit on a monthly fee does not compensate a customer whose checkout was down through a sales peak. Both sides should understand the credit as a shared acknowledgement rather than as damages.
A termination right is the clause that has teeth. For an enterprise buyer, the right to leave after sustained failure matters far more than a percentage rebate.
SLA vs KPI
These get used interchangeably and they are not the same thing.
| SLA | KPI | |
|---|---|---|
| What it is | A contractual commitment with consequences | An internal performance measure |
| Who it is for | The customer | The team |
| What happens when missed | A financial or contractual remedy | Investigation and course correction |
| Who agrees it | Both parties, in writing | The team that owns it |
The distinction that matters in practice: an SLA is external and has consequences; a KPI is internal and has a conversation. Missing a KPI starts an investigation. Missing an SLA starts a claim.
A useful discipline is to run internal targets tighter than the external agreement, so you find out you are drifting before your customer does. If the SLA says 99.9%, an internal objective at 99.95% gives you room to react. The mechanics of doing this properly live in service level objectives, the service level indicators you measure them with, and error budgets.
How to write an SLA that holds
Six steps, in this order. The order is the point: most bad SLAs are written backwards, starting from a number somebody liked.
- Measure first. Take at least a quarter of real availability data before you promise anything. An SLA written from an aspiration is a bet.
- Pick metrics you already collect. If you cannot produce the number today, you cannot defend it in a dispute.
- Set the target below your measured performance. If you have been running 99.93%, commit to 99.9%, not 99.95%. The gap is your operating room.
- Define measurement precisely. Whose monitoring, from where, over what window, and what counts as an outage. Write down how partial degradation is treated, because that is the argument you will actually have.
- Write the exclusions honestly. Scheduled maintenance windows, third-party dependencies, customer-side failures. An SLA with no exclusions is not generous, it is unserious.
- Set a review cadence. Annually at minimum. Services change and a stale agreement eventually describes a system nobody is running.
Five common SLA mistakes
Promising nines the architecture cannot deliver. Covered above, and it is the most expensive mistake on this list because it is invisible until the month you miss.
Measuring from the wrong place. Monitoring from inside your own network will report availability your customers did not experience. Measure from where the customer sits.
No definition of partial degradation. A service that is up but responding in eleven seconds is down as far as a user is concerned. If the agreement is silent, both sides will read it in their own favor.
Confusing the SLA with the internal target. Publishing one number and operating to the same number leaves no margin. See the SLA vs KPI section.
Never reviewing it. The most common failure of all, and the least dramatic. Agreements signed three years ago routinely describe services that have since been rearchitected twice.
What All Quiet does with this
We publish our own SLA rather than describing one in the abstract, and service level transparency covers why that is worth doing. The connection to incident response is direct and worth stating plainly. Availability commitments are won or lost in the minutes between something breaking and somebody qualified working on it. The worked example above spent 15 of its 68 minutes on detection and acknowledgement alone, before any diagnosis began. That portion is a routing and escalation problem, and it is the part of an SLA that tooling can actually move. See how teams run on-call and escalation with our incident response platform.
Frequently Asked Questions
What does SLA mean?
SLA stands for service level agreement. It is a documented commitment between a provider and a customer that names what will be delivered, how it will be measured, and what happens if targets are missed.
What is included in an SLA?
A usable SLA names the services covered, the metrics and measurement method, the targets, responsibilities on both sides, exclusions, and the remedies or review cadence when a target is missed.
What happens if an SLA is breached?
Most commercial SLAs settle breaches with service credits against a future invoice, often on a tiered basis. Customers usually must request credits within a defined window, and sustained failure may include a termination right.
Who is responsible for meeting an SLA?
Both parties share responsibility. The provider must deliver and measure the service; the customer must report issues promptly and meet any obligations defined in the agreement, such as providing information needed for diagnosis.