We use analytics cookies.We use cookies to analyze site traffic and improve your experience.
Loading...
System Design and AI Engineering, by Roni Das. 984 interactive lessons.
Start LearningAdvanced · Reliability & Resilience
Service Level Agreement: a contractual commitment between provider and customer specifying uptime, response time, and penalties for breaches. The business version of an SLO.
In short
An SLA (Service Level Agreement) is a contract between a service provider and its customer that promises specific levels of service, such as 99.9 percent monthly uptime, and spells out what the provider owes the customer (usually service credits or refunds) when those promises are missed.
In short
An SLA (Service Level Agreement) is a contract between a service provider and its customer that promises specific levels of service, such as 99.9 percent monthly uptime, and spells out what the provider owes the customer (usually service credits or refunds) when those promises are missed.
Learn it in the course
This page is the free part.
₹1,111 in India$25 everywhere elseonce, for the whole course
The System Design course covers SLA across a run of lessons, not one page. These 4 alone are about 55 minutes of step-by-step reading, every one with a quiz.
The legally binding reliability promise, when missing your targets has financial consequences.
Putting it all together, how SLIs, SLOs, and SLAs work as a unified reliability framework.
Measuring and optimizing response times, throughput, and resource usage to meet performance SLAs.
Measuring how reliably your system serves requests, the nines that define your reputation.
all part of
System Design Masterclass
770 lessons · about 287 hours · 18 free to read
₹1,111in India, by UPI
$25everywhere else, by PayPal
It is really nice and good Please join the course
You own this course
Continue with SLA (Service Level Agreements)pay once,
yours for life
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 100 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.
Amazon Web Services
Publishes per-service SLAs such as 99.9 percent monthly uptime for S3 Standard and pays out tiered service credits when breached.
Google Cloud
Compute Engine and other products carry monthly uptime SLAs with credit tiers of 10, 25, and 30 percent as availability degrades.
Cloudflare
Enterprise plans include a 100 percent uptime SLA for the core network, with 25x credit multipliers for downtime above the promised level.
Microsoft Azure
Offers financially backed SLAs per service, for example 99.99 percent for VMs in availability zones, with credits filed through the support portal.
An SLI is the raw measurement (for example, percentage of successful requests). An SLO is the internal target you aim for. An SLA is the contractual promise to customers, usually set below the SLO so you have a safety buffer before you owe credits.
About 43 minutes 12 seconds per month, or roughly 8 hours 46 minutes per year. Adding a nine to 99.99 percent cuts that to about 4 minutes 19 seconds per month.
In almost all cases you get a service credit on a future bill, not cash or compensation for your lost revenue. You usually have to file a claim within 30 to 60 days with your own evidence, and the credit is capped well below the real cost of the outage.
Because every extra nine of reliability multiplies engineering cost, and because they want a buffer. Promising 99.9 percent while internally targeting 99.99 percent means normal hiccups never trigger payouts and the provider limits its liability.
Not reliably. Your achievable SLA is bounded by the weakest dependency in your stack. To exceed a single provider's SLA you need redundancy across regions or providers so one outage does not take you down.
SLA/SLO/SLI Overview
Putting it all together, how SLIs, SLOs, and SLAs work as a unified reliability framework
Performance Testing
Measuring and optimizing response times, throughput, and resource usage to meet performance SLAs
Availability Metrics
Measuring how reliably your system serves requests, the nines that define your reputation
Slack Notifications
Real-time team alerts in Slack channels. ChatOps integration for incident response
Master-Slave Replication
The most common replication topology, one writer, many readers, and the trade-offs that come with it
SLO
Service Level Objective: a target value for an SLI, like '99.9% of requests under 300ms.' The internal engineering goal that drives reliability investment.
SLI
Service Level Indicator: a quantitative measure of service behavior, like the proportion of requests faster than 300ms. The raw metric that feeds SLOs.
Availability
The percentage of time a system is operational and accessible. Measured in 'nines', 99.99% availability means about 52 minutes of downtime per year.
Chaos Engineering
Deliberately injecting failures into a system to test its resilience. Netflix's Chaos Monkey randomly kills servers to ensure the system survives.
Back Pressure
A flow control mechanism where a slow consumer signals upstream producers to slow down. Prevents systems from being overwhelmed by data they can't process.
Error Budget
The allowed amount of unreliability derived from SLOs. If your SLO is 99.9% uptime, your error budget is 0.1% (about 43 minutes/month). Once exhausted, freeze deployments.
This page explains the idea. The "SLA (Service Level Agreements)" lesson builds it up step by step, with diagrams. It is part of the System Design Masterclass course, which has 770 lessons. 18 of them are free to read. You pay once and keep it for life, with no subscription.
Open the SLA (Service Level Agreements) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about SLA in an interview?
Each question has why it is asked, a full answer, what the interviewer listens for, the follow-ups, the common mistakes and a diagram (268 diagrams in all). A PDF you keep, junior to staff level.
India: UPI, cards or netbanking through Razorpay. Elsewhere: card or PayPal. Download at once from My packs.
