What is an SLA (service level agreement)?
An SLA (service level agreement) is a formal commitment from a service provider about the level of service you can expect — most often the availability or uptime of a service — usually backed by financial credits if the provider fails to meet it. It turns a vague promise ("this service is reliable") into a specific, contractual one that can be measured and, if broken, compensated. Every cloud service tends to carry its own SLA, and the terms vary from one to the next, so this guide explains the concept rather than any single number. It also covers how an SLA relates to the internal targets and measurements teams use day to day, and where SLAs fit into how you architect for reliability.
The plain idea
An SLA is, at its core, a promise with consequences. A provider states what level of service it commits to delivering — typically expressed as availability over a billing period — and what happens if it falls short, usually in the form of service credits applied to a future bill. It is a contractual document, not a technical guarantee that nothing will ever go wrong; it defines what the provider owes you when something does.
What SLAs typically cover
Most cloud SLAs focus on one or more of the following:
- Availability or uptime — the proportion of time a service is expected to be operational and reachable.
- Performance — for some services, commitments around latency or response time, not just whether the service is up.
- Support response times — for support plans, how quickly the provider commits to responding to a raised issue, based on its severity.
The "nines," conceptually
Cloud SLAs are often talked about in terms of "nines" of availability — more nines meaning a stricter commitment and less permitted downtime. The general idea worth understanding is that each additional nine represents a meaningfully tighter bar, not a small step up, and that achieving it typically demands correspondingly more redundant architecture. Exactly what percentage or downtime allowance a given service commits to is specific to that service and changes as providers update their terms, so rather than quoting a figure here, treat the provider’s own SLA page as the source of truth whenever a specific commitment matters to a decision you are making.
SLA vs SLO vs SLI
These three terms are related but distinct, and mixing them up is a common source of confusion. The SLA is the external, contractual commitment made to a customer. An SLO (service level objective) is an internal target a team sets for itself, often stricter than the SLA it supports, used to guide day-to-day engineering decisions before anything reaches the point of breaching a customer-facing promise. An SLI (service level indicator) is the actual measurement — the real, observed number, such as the proportion of successful requests over a period — that tells a team whether it is meeting its SLOs. This trio sits close to the broader discipline of observability, covered in our what is observability explainer: you cannot know whether you are meeting any of these commitments without first measuring the right things.
What an SLA does not promise
An SLA usually covers the provider’s own service — a managed database staying reachable, for instance — not the overall availability of the application you build on top of it. Your application’s real-world availability depends on your own architecture: how you combine services, whether you have built in redundancy, and how you handle the failure of any single dependency. Our explainer on high availability vs fault tolerance covers the architectural side of this directly. It is also worth being clear-eyed that service credits, however generous, rarely come close to compensating the full business impact of an outage — they are a contractual remedy, not an insurance policy against the cost of downtime.
How SLAs inform architecture
In practice, SLAs are an input to design decisions rather than a substitute for them. Knowing the SLA of each managed service you depend on tells you where the weak points in your overall system might be, and lets you decide where additional redundancy is worth building — spreading a workload across multiple availability zones, adding failover, or accepting a lower-tier service where the impact of downtime is minor. Reliability is something you design for by combining services thoughtfully, using published SLAs as one of the inputs to that design.
Original practice questions, timed mock exams and revision notes. No card, nothing to pay.