Aliases: Service Level Agreement
SLA (Service Level Agreement)
A documented commitment to service availability, performance, or support response times.
Last reviewed: July 25, 2026
What is an SLA?
An SLA is a formal promise — usually in a contract — about how a service will perform. Common metrics include uptime percentage, response time, and support ticket response hours.
Uptime examples
| SLA | Max downtime per year (approx.) |
|---|---|
| 99% | 3.65 days |
| 99.9% | 8.76 hours |
| 99.99% | 52.6 minutes |
SLA vs SLO vs SLI
| Term | Meaning |
|---|---|
| SLI (Indicator) | Measured metric — e.g., successful requests / total |
| SLO (Objective) | Internal target — e.g., 99.95% success rate |
| SLA (Agreement) | Customer-facing commitment with remedies |
Remedies
Enterprise SLAs often include service credits if uptime falls below threshold. Credits are typically a percentage of monthly fees, not full refunds.
Reading SLAs critically (informational)
- Check measurement window and exclusions (scheduled maintenance, force majeure)
- Understand calculation method — regional vs global, monthly vs quarterly
- Distinguish marketing “uptime” from contractual SLA in paid plans
In cloud provider context
AWS, Azure, and Google publish SLAs per product (S3, Compute Engine, etc.). Your SaaS SLA to customers is separate from SLAs your vendors give you.
What people get wrong
- Believing the percentage is the promise. The definitions section is the promise: what counts as “down,” which requests are excluded, and how the window is measured decide everything.
- Confusing credits with compensation. A 10% service credit on a $500/month bill does not cover a day of lost revenue; SLAs are accountability signals, not insurance.
- Promising customers a higher SLA than your dependencies give you. Your availability is bounded by everything you sit on — multiply it out (try our SLA calculator).
SLA Credits and Their Practical Limits
Most cloud provider and SaaS SLAs specify service credits — a percentage refund of the affected billing period — as the remedy when availability falls below the guaranteed threshold, rather than compensating for the actual business impact an outage may have caused. This distinction matters significantly in practice: a service credit covering a small fraction of a monthly bill is rarely proportional to the revenue or reputational damage an extended outage might cause a business relying on that service, which is why SLAs should be understood as a signal of a provider’s confidence in their own reliability and a modest consolation mechanism, rather than a genuine insurance policy against the real costs of downtime — critical systems typically need independent resilience measures (redundancy, failover, monitoring) regardless of what SLA a vendor offers.
Enterprise procurement teams reviewing a vendor SLA should read the exclusions section as carefully as the headline uptime number, since scheduled maintenance windows, force majeure events, and issues attributed to the customer’s own configuration are commonly carved out of the guarantee entirely.
Historical figures and technical concepts for informational purposes only. Not technical, professional, legal, or financial advice. Sources: Official Documentation.