A service level agreement (SLA) is a formal commitment between a service provider and its customer that defines measurable targets for a service, such as availability or response time, together with how they are measured and what remedy applies when they are missed. In cloud services, SLAs typically promise monthly uptime percentages and compensate breaches with service credits.
In observability, the SLA sits at the top of a three-level hierarchy: service level indicators measure behavior, service level objectives set internal targets on those indicators, and the SLA turns a looser version of those targets into an external promise. Observability data is what proves whether the promise was kept.
What a service level agreement contains
A usable SLA is precise enough that both parties can calculate compliance from the same data. It names the covered service, the metric, the measurement window, the exclusions and the remedy. Vague wording such as “high availability” without a definition of downtime leads to disputes rather than accountability.
| Component | What it defines | Example |
|---|---|---|
| Service scope | Which products and configurations are covered | Virtual machines deployed across two zones |
| Metric | What is measured | Monthly uptime percentage |
| Downtime definition | When the service counts as unavailable | Error rate above 5 percent for one minute |
| Measurement period | The window over which compliance is calculated | One calendar month |
| Exclusions | Events that do not count | Scheduled maintenance, customer misconfiguration |
| Remedy | Compensation for a breach | Credit of 10 to 100 percent of the monthly fee |
| Claim process | How and when the customer requests the remedy | Request within 30 days with evidence |
Most cloud SLAs require the customer to file a claim, and credits are capped at the fee for the affected service. The SLA therefore limits the provider’s financial exposure; it is not insurance against business losses caused by an outage.
What availability percentages mean
Availability targets are usually expressed in nines, and each additional nine reduces the allowed downtime by a factor of ten. Translating a percentage into minutes is the quickest way to judge whether a target is realistic.
| Availability | Downtime per 30-day month | Downtime per year |
|---|---|---|
| 99 percent | About 7.2 hours | About 3.65 days |
| 99.9 percent | About 43 minutes | About 8.8 hours |
| 99.95 percent | About 22 minutes | About 4.4 hours |
| 99.99 percent | About 4.3 minutes | About 53 minutes |
| 99.999 percent | About 26 seconds | About 5.3 minutes |
Cloud providers often offer higher SLA tiers for redundant deployments: a single virtual machine may carry a lower commitment than instances spread across availability zones. The architecture chosen by the customer therefore determines which SLA applies, and an application built on several services has a composite availability lower than any single component, because the probabilities multiply.
SLA, SLO and SLI compared
The three terms form a chain from measurement to promise. Confusing them is common, so the distinction is worth stating precisely.
| Term | Nature | Audience | Consequence of a miss |
|---|---|---|---|
| Service level indicator | A measured ratio or value | Engineering teams | None by itself |
| Service level objective | An internal target on an indicator | Engineering and product | Error budget spent, reliability work prioritized |
| Service level agreement | An external commitment with remedies | Customers, legal, finance | Credits, penalties or contract termination |
A sound practice is to set the SLO stricter than the SLA. If the SLA promises 99.9 percent, the internal SLO might be 99.95 percent, so the team reacts when the error budget runs low, well before a contractual breach. Teams that set the SLO equal to the SLA discover problems only when credits are already owed.
Measuring SLA compliance with observability data
Proving compliance requires trustworthy measurement. Providers measure from their own infrastructure, while customers often run independent synthetic probes and analyze request metrics, logs and traces to build their own evidence. The two views can disagree, which is why the downtime definition in the SLA matters so much.
| Approach | Strength | Weakness |
|---|---|---|
| Synthetic probes | Simple and independent of traffic | Sees only the tested paths |
| Server-side request metrics | Covers real traffic precisely | Misses failures before requests arrive |
| Client-side telemetry | Reflects the user experience | Noisy, affected by user networks |
| Provider status data | Matches the provider’s own calculation | Not independent |
Good practice is to define SLA reporting as a request-based ratio of successful requests to valid requests where possible, store the raw data long enough to cover the claim window, and align time windows and time zones with the contract. Metrics from tools such as Prometheus, visualized in Grafana or Datadog, can then produce a monthly compliance report that both sides accept.
Common pitfalls with SLAs
- Promising more nines than dependencies allow: a service cannot reliably exceed the combined availability of the cloud services beneath it.
- Measuring only uptime: a service that responds slowly or returns errors may still count as up unless latency and error rates are defined.
- Overlooking exclusions: maintenance windows and force majeure clauses can remove most real incidents from the calculation.
- Assuming credits cover losses: credits rarely approach the business cost of an outage.
- No internal SLO: without a stricter internal target, the first warning of trouble is a customer claim.
An SLA is ultimately a business instrument. It should reflect what the engineering organization can sustain, which means negotiating it with evidence from historical observability data, not with marketing targets.
Explained without jargon
A service level agreement is a written promise about how well a service will work. A cloud provider might promise that a service will be working 99.9 percent of the time each month.
The agreement also says what happens if the promise is broken. Usually the customer gets a discount on the next bill. It does not pay for the trouble the outage caused. Smart teams therefore aim higher internally than they promise externally.
A typical use case
A software company sells a payroll platform to mid-sized employers and offers an SLA of 99.9 percent monthly availability, with a 10 percent credit below that level and 25 percent below 99 percent. Downtime is defined as more than 5 percent of API requests failing over a one-minute interval, excluding announced maintenance.
Internally, the reliability team sets an SLO of 99.95 percent, which leaves an error budget of about 22 minutes per month. Request metrics feed a dashboard that tracks budget consumption in real time. In one month a database failover consumes 15 minutes of budget, and the team freezes risky releases for the rest of that month. The month closes at 99.96 percent, no credits are owed, and the compliance report generated from the same metrics is shared with the largest customers as evidence.