SLA

An SLA is the business-facing promise about how reliable a service will be. It is written into a contract, signed by both sides, and carries money behind it. If the provider falls short, the customer gets compensated, usually as a credit on the next bill.

The number you see most often is availability, written as a percentage of time the service is reachable over a billing period. AWS S3, for example, has a 99.9 percent monthly uptime SLA for standard storage. That sounds tiny, but the gap between 99.9 and 99.99 percent matters: 99.9 percent allows about 43 minutes of downtime per month, while 99.99 percent allows only about 4 minutes 19 seconds. The famous nines table is worth memorizing because each extra nine costs an order of magnitude more engineering effort.

An SLA is not the same as an SLO or an SLI, though people mix them up. An SLI (Service Level Indicator) is the raw measurement, for example the fraction of HTTP requests that returned 200 in the last 30 days. An SLO (Service Level Objective) is the internal target you hold yourself to, say 99.95 percent. The SLA is the weaker, contractual line you promise customers, often set below the SLO so you have a safety buffer before you owe anyone money.

Every real SLA has three parts: the metric, the measurement window, and the remedy. The metric defines exactly what is being promised, for example uptime, p99 latency under 300 ms, or successful-request rate. The window is the period over which it is calculated, usually a calendar month. The remedy is what the customer collects when the target is missed.

The remedy is almost always a service credit, not cash and not damages for your lost revenue. Google Cloud's Compute Engine SLA is typical: drop below 99.99 percent monthly and you get a 10 percent credit, below 99 percent and you get 25 percent, below 95 percent and you get 30 percent. The credit caps out well below the actual cost of an outage to the customer, which is the point. The SLA limits the provider's liability as much as it reassures the buyer.

The fine print decides who really wins. SLAs exclude scheduled maintenance windows, force majeure events, problems caused by the customer's own misconfiguration, and anything outside the provider's network. They also put the burden of proof on the customer: you usually have to file a claim within 30 to 60 days with your own monitoring logs as evidence. Providers measure from their own vantage point, so an outage you experienced through a flaky region might not count if their global dashboard stayed green.

SLAs matter most when you are buying infrastructure your own product depends on, or selling to enterprises whose procurement teams will not sign without one. A startup buying a managed database cares whether the vendor promises 99.95 or 99.99 percent because that number flows directly into the SLA the startup can offer its own customers. You cannot promise more reliability than the weakest dependency in your chain.

The hard trade-off is that a tighter SLA forces real engineering spend. Going from 99.9 to 99.99 percent typically means multi-region failover, automated rollback, redundant load balancers, and an on-call rotation that can respond in minutes. Each nine multiplies cost, so providers price higher tiers accordingly and most teams deliberately promise less than they can actually deliver to keep a buffer.

There is also a behavioral trap. Teams sometimes treat the SLA as a target and run the service right at the line, burning their entire error budget every month. Healthy practice is to set the internal SLO comfortably above the contractual SLA, track the error budget, and slow down risky launches when the budget runs low. The SLA should be the floor you never want to touch, not the goal.

Say you run a payments API and you sell a 99.9 percent monthly uptime SLA to your merchants. That budget is roughly 43 minutes of downtime per month. Internally you set an SLO of 99.95 percent, which is about 22 minutes, so you have a buffer before any merchant can claim a credit.

One month a bad deploy takes the API down for 35 minutes. You blew the internal SLO but stayed inside the contractual SLA, so you owe no credits, but your error budget for the month is spent. The on-call team freezes non-critical deploys for the rest of the month while they add a canary rollout and faster automated rollback.

The next month a regional outage at your cloud provider knocks you out for 70 minutes. Now you have breached your own 99.9 percent SLA. Merchants who file a claim within your stated window get the contracted credit, say 10 percent of their monthly bill. You in turn file your own claim against your cloud provider under their SLA, recovering a credit from them. The credits rarely cover the real business damage, which is exactly why the engineering investment to avoid the breach is worth far more than the SLA payout.