Service Level Agreement (SLA): The Contract Behind Uptime

WHY IT EXISTS Customers need predictable, reliable services to build their own businesses on. A handshake isn't enough. An SLA provides a formal, legally binding definition of "what good looks like" and establishes clear consequences for failing to meet that standard, turning a vague promise of reliability into a measurable commitment.

THE MENTAL MODEL An SLA is a business contract that uses technical metrics. Think of it like a warranty for a service. If your car's engine is warrantied for 100,000 miles, the manufacturer makes a binding promise. If it fails at 80,000 miles, there are consequences. An SLA does the same for service uptime or performance. It's not the engineering team's internal goal; it's the floor below which the business starts paying penalties, like service credits.

HOW IT WORKS An SLA is a contractual promise about a service's performance, built upon technical metrics. It specifies remedies for failure. The process starts with a Service Level Indicator (SLI), which is what you measure (e.g., uptime percentage). Then, an internal Service Level Objective (SLO) is set as a target (e.g., 99.95% uptime). The SLA is the customer-facing promise, often set slightly lower than the SLO (e.g., 99.9% uptime). If the service fails to meet the SLA, the provider owes the customer a remedy as defined in the contract.

WHEN TO USE IT SLAs are essential for any service sold to external customers, especially in B2B contexts where another business depends on your service's availability. They are the foundation of trust for cloud providers, API services, and managed software. They can also be used internally between departments in a large organization to create accountability, for example, between a platform team and a product team.

WHEN NOT TO USE IT Avoid SLAs for internal projects during early development or for services with no external customers. Imposing a formal SLA too early can stifle innovation and create unnecessary overhead. The primary purpose is to manage customer expectations and business risk, not to be a project management tool for internal-only, non-critical systems. An SLO is often sufficient for internal goal-setting without the contractual weight of an SLA.

ONE CANONICAL EXAMPLE A cloud storage provider might offer an SLA of 99.9% monthly uptime. Their internal SLO might be 99.95%. The SLI is system availability. If, in a 30-day month (43,200 minutes), the service is down for more than 43.2 minutes (0.1%), the provider has breached the SLA. The contract would then specify a remedy, such as giving the customer a 10% credit on their monthly bill. The buffer between the SLO and SLA gives engineering a margin for error before a failure costs the company money.