An SLA (service level agreement) is a contract between a service provider and its customers that commits to measurable service levels, such as 99.95 percent monthly availability, and defines what happens if they are missed, typically service credits. It is based on SLIs, should be looser than internal SLOs, and specifies measurement, exclusions and claims.
What is an SLA?
An SLA (service level agreement) is a formal commitment from a provider to its customers about the level of service they can expect. Typical SLAs promise a minimum availability per month, sometimes also response times for support or maximum latency, and they define a remedy if the provider falls short. In cloud and SaaS contracts the usual remedy is a service credit: a percentage of the monthly fee credited back to the customer.
An SLA is a business and legal document first. It answers the question: what has the provider promised, how is it measured, and what does the customer get if the promise is broken?
SLA vs. SLO vs. SLI
The three terms build on each other and are often confused:
| Term | What it is | Example | Audience |
|---|---|---|---|
| SLI (service level indicator) | A measurement of service behavior | Share of successful HTTP requests per minute | Engineering |
| SLO (service level objective) | An internal target for an SLI over a window | 99.95% successful requests over 28 days | Engineering and product |
| SLA (service level agreement) | A contractual promise with consequences | 99.9% monthly availability, otherwise service credit | Customers, legal, sales |
The rule of thumb: the SLO is stricter than the SLA. If your internal objective is 99.95 percent and your contract promises 99.9 percent, the gap gives engineers room to detect and fix problems through error budgets and burn rate alerts before a contractual breach occurs.
What availability numbers mean
Availability targets translate into an allowed amount of downtime. For a 30-day month:
| Availability | Downtime per 30-day month | Downtime per year |
|---|---|---|
| 99% | about 7.2 hours | about 3.65 days |
| 99.9% | about 43 minutes | about 8.8 hours |
| 99.95% | about 22 minutes | about 4.4 hours |
| 99.99% | about 4.3 minutes | about 53 minutes |
Each additional nine costs significantly more engineering effort. Also remember composite availability: a service that depends serially on three components with 99.9 percent each can at best reach about 99.7 percent unless it adds redundancy.
What a good SLA contains
- Scope: which services, regions and plans the SLA covers.
- Definition of availability: what counts as unavailable, for example error rate above a threshold for a minute, measured by the provider's monitoring.
- Measurement window: usually a calendar month.
- Exclusions: scheduled maintenance, force majeure, issues caused by the customer or by third-party services.
- Service credits: a tiered schedule, for example (illustrative) 10 percent of the monthly fee below the target and 25 percent below a lower threshold, often capped.
- Claim process: how and within which period the customer must request credits. Credits are often not applied automatically.
How to set an SLA as a provider
- Start from measured reality. Look at the availability your service actually achieved over the last six to twelve months, measured with customer-facing SLIs.
- Set the internal SLO first. Choose an objective the team can sustain and defend with an error budget policy.
- Leave a margin. Put the contractual SLA below the SLO so that a bad week does not immediately cost money.
- Account for dependencies. Cloud regions, DNS, CDNs and third-party APIs all have their own SLAs, and your promise cannot sensibly exceed what your critical path can deliver.
- Write precise definitions. Agree with legal on what counts as downtime, how it is measured and which events are excluded, before the first incident tests the wording.
Monitoring an SLA
From the customer side, you want independent evidence: synthetic checks from several locations against the provider's endpoints, plus the error rate and latency your own services see when calling them. From the provider side, the SLA should be backed by SLIs that measure what customers experience, not only internal health checks. In both cases, keep the raw data long enough to support a claim or an audit, and document every breach with a timeline and a postmortem.
Common mistakes
- Setting the SLA equal to the SLO, which leaves no margin before a contractual breach.
- Promising availability on components you do not control, without accounting for dependencies.
- Vague definitions of downtime that lead to disputes about whether a breach happened.
- Treating service credits as compensation for business loss. Credits are usually small and often the sole remedy.
How Obseria helps
Obseria itself is backed by a 99.95 percent SLA. Within the platform, you can define SLIs and SLOs on any signal, track error budgets and burn rate, run synthetic checks from more than 50 locations, and publish status pages so that customers see the same availability data you report against your own SLAs.