SLA

SLA stands for “Service Level Agreement.” It is part of a contract between a provider and its customer. It doesn’t state what the service can do, but how well it must function. Typical commitments are: The service is available 99.9 percent of the time. Or: We respond to an urgent incident report within one hour. It’s important that these points are formulated in a measurable way. “We strive to provide good service” is not an SLA, because it cannot be verified.

What a promised availability is really worth

Companies today build their own products on top of other people’s services. An online shop uses a payment provider, an app runs on rented servers, a customer chat runs on another company’s AI model. If one of these building blocks fails, the company’s own product comes to a standstill too. The SLA is the only reliable statement about how often you have to expect such a standstill.

Behind the percentage figures lie very different amounts of downtime. 99 percent availability sounds good, but allows for around three days of downtime per year. 99.9 percent means just under nine hours, 99.99 percent only about 53 minutes. In the industry, people speak of “three nines” or “four nines.” Each additional nine costs the provider a lot of money, because it has to maintain technology two or three times over. That’s why it’s also more expensive in the contract.

A common misconception: an SLA does not prevent outages. It only regulates what happens afterward. Usually the customer receives a credit, around ten percent of the monthly bill. If a shop loses revenue in the six-figure range on a day of downtime, that’s little consolation. So an SLA is more of a quality promise with a penalty than an insurance policy.

From measurement to credit

An SLA always consists of three parts. First, the metric: what exactly is measured? Second, the target value: what value must be achieved? Third, the consequence: what happens in the event of a breach? Besides availability, two other metrics are common. Response time states how long a single request may take. Reaction time states how quickly support gets back to you.

What matters is the fine print, because that’s where the exceptions are. Planned maintenance work almost never counts as downtime if it was announced in advance. Problems within the customer’s own network are also excluded. And usually the customer must report and document the breach themselves, often within a few weeks. Anyone who misses this gets nothing, even if the outage was undisputed.

The SLA should be distinguished from two similar terms. An SLO is an internal goal that a team sets for itself, without legal consequences. Terms of service, on the other hand, regulate what is allowed, not how well the service runs. Only the SLA is a legally enforceable commitment regarding quality.

SLAs at cloud providers and AI services

SLAs are most visible at the major providers of rented computing power, namely Amazon, Microsoft, and Google. They publish their commitments publicly on their websites. Anyone renting a database there can look up which availability applies to which pricing tier. In the event of outages, the figures later appear in customers' quarterly reports, when compensation becomes due.

SLAs are currently a major topic among AI providers. A model sometimes responds quickly and sometimes slowly, because many users share the same graphics chips. But anyone building a product on top of it needs reliable response times. That’s why providers like OpenAI or Anthropic sell business customers more expensive tiers with fixed commitments. Private users, by contrast, usually get no SLA at all.

In the news, you typically encounter the term after major outages. It will state how many hours a service was offline and whether the SLA threshold was breached. It also appears in job listings, for example when an operations team is supposed to monitor SLAs. And if your school or club rents software, there’s a high probability that one is included in the contract as well.