Reading a Cloud SLA Properly
An SLA is a billing commitment with conditions attached. Reading the conditions is where the useful information is.
A service level agreement states an availability target and what the provider owes you if they miss it. What they owe is service credits — a percentage of that month’s spend on the affected service. It is a billing remedy, not compensation for your losses.
What the numbers mean
| Target | Monthly downtime allowed | Typical credit if missed |
|---|---|---|
| 99.99% | 4.3 minutes | 10% |
| 99.9% | 43 minutes | 10–25% |
| 99.0% | 7.2 hours | 25–100% |
| Below 95% | 36+ hours | Often 100% |
Note the shape: even a severe outage returns a percentage of one month’s bill for one service. If downtime costs your business more than that, the SLA is not your protection — your architecture is.
The conditions that change everything
- Architecture requirements. The headline figure usually assumes multiple availability zones. A single instance typically carries a much lower commitment, or none.
- Scope. The SLA covers one service in one region. A dependency failing elsewhere may not count.
- Definition of unavailable. Usually complete inability to connect. Severe slowness often does not qualify.
- Exclusions. Scheduled maintenance, your own configuration errors, and factors outside the provider’s control.
- Claim process. Credits are almost never automatic. You must file a claim, usually within 30 to 60 days, with evidence.
The claim process point is practical and frequently missed. Providers do not proactively credit accounts; if you do not ask, you do not receive.
Composite availability
Your application’s availability is the product of its dependencies, not the best number among them.
A stack using a load balancer at 99.99 per cent, compute at 99.99 per cent, a database at 99.95 per cent and DNS at 100 per cent has a theoretical ceiling of roughly 99.93 per cent — about 30 minutes a month — even if nothing you built ever fails.
Reducing the number of things that can independently fail is often more effective than improving any one of them.
What SLAs do not cover
- Your own bugs and misconfigurations, which cause more downtime than provider failures.
- Data loss, which is covered by durability commitments rather than availability ones.
- Performance degradation short of unavailability.
- Third-party services you depend on.
- Account suspension or billing problems.
- Your business losses, in any amount exceeding the credits.
How to use them
- Read the architecture requirement, and build to it if you want the headline number.
- Calculate composite availability across your dependencies, not per service.
- Compare the SLA against what downtime actually costs you, and design to the gap.
- Monitor independently — you need your own evidence to claim, and the provider status page is often conservative.
- Note the claim window and actually file when an outage occurs.
- Treat SLAs as a floor on provider seriousness, not as a guarantee of your uptime.
Free tiers and preview services
Free-tier resources and services in preview or beta usually carry no SLA at all. That is fine for development and worth knowing before something important depends on one.
The same applies to some spot and preemptible capacity, which is explicitly interruptible by design.
Common questions
Are credits automatic?
Almost never. You must file a claim within a defined window with evidence of impact. Set a reminder to do it after any significant outage.
Does a higher SLA mean better service?
It means a stronger contractual commitment and usually a more redundant architecture requirement. Actual reliability is better judged from historical incident records than from the target.
Do VPS providers offer SLAs?
Most publish one, often around 99.9 per cent with credits. The commitments are typically simpler and the credit percentages smaller than hyperscaler equivalents.
Should an SLA drive provider choice?
Rarely as the deciding factor. Historical reliability, region coverage, support quality and the fit of the services matter more in practice.
Where to go next
Read next
Serverless, Explained Without the Marketing
There are servers. You do not manage them, you do not pay for them when idle, and you do not control very much about…
Cloud Terminology, Translated
The same concept has three names depending on the provider. Here is the translation table, plus the terms that…
Containers vs Virtual Machines
Both run your application in isolation. They isolate at different layers, and that difference explains everything…