100% Free Forever
AI-Powered Learning
Industry Expert Content
Certificates & Badges
Learn At Your Own Pace
DevOps

Service Level Agreement (SLA)

BeginnerConcept11.9K learners

A Service Level Agreement (SLA) is a formal, often contractual commitment between a service provider and its customers that defines the level of service — such as uptime or response time — the provider guarantees, along with the…

Definition

A Service Level Agreement (SLA) is a formal, often contractual commitment between a service provider and its customers that defines the level of service — such as uptime or response time — the provider guarantees, along with the consequences if it fails to deliver.

Overview

An SLA is the external, customer-facing counterpart to an internal Service Level Objective (SLO). Where an SLO is a target a team sets for itself to guide engineering decisions, an SLA is a promise made to paying customers, frequently backed by remedies like service credits, discounts, or termination rights if the provider fails to meet it. Cloud and SaaS vendors commonly publish SLAs guaranteeing a specific uptime percentage — 99.9% or 99.95% are typical — measured over a monthly or annual period. Because an SLA carries real financial and reputational consequences, responsible providers set it more loosely than their internal SLO, so that ordinary operational variance doesn't trigger a breach. This buffer is why the error budget derived from an internal SLO acts as an early-warning system: a team notices it's burning through budget well before it ever risks violating the SLA a customer is relying on. SLAs typically also define what counts as downtime, how it's measured, exclusions such as scheduled maintenance, and the process for customers to claim remedies. In B2B software and cloud infrastructure, SLAs are a standard part of vendor contracts and procurement decisions, and platform teams practicing site reliability engineering (SRE) generally treat SLA compliance as a hard floor, not a target to aim for.

Key Concepts

  • A formal, often contractual promise made to external customers
  • Usually paired with financial remedies — credits, refunds, or termination rights — on breach
  • Defines precisely how uptime or performance is measured and what counts as an exclusion
  • Set more loosely than the internal SLO so normal variance doesn't trigger penalties
  • Common in cloud, SaaS, and infrastructure vendor contracts
  • Reviewed by legal and procurement teams, not just engineering

Use Cases

Guaranteeing uptime percentages for cloud infrastructure or SaaS products
Setting customer expectations and remedies for support response times
Forming the basis of vendor procurement and contract negotiation
Triggering automatic service credits when a provider misses its committed uptime
Providing a legal floor that internal SLOs are deliberately set above

Frequently Asked Questions

From the Blog