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 Objective: a target value for an SLI, like '99.9% of requests under 300ms.' The internal engineering goal that drives reliability investment.
In short
A Service Level Objective (SLO) is a specific, measurable reliability target you set for a service, such as "99.9% of requests succeed in under 300ms over a rolling 28 days." It turns a vague goal like "the site should be fast and up" into a number engineers can measure, alert on, and be held to.
In short
A Service Level Objective (SLO) is a specific, measurable reliability target you set for a service, such as "99.9% of requests succeed in under 300ms over a rolling 28 days." It turns a vague goal like "the site should be fast and up" into a number engineers can measure, alert on, and be held to.
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 SLO across a run of lessons, not one page. These 4 alone are about 84 minutes of step-by-step reading, every one with a quiz.
The reliability targets you set for your SLIs, the line between 'acceptable' and 'we need to fix this'.
Putting it all together, how SLIs, SLOs, and SLAs work as a unified reliability framework.
The quantified amount of unreliability you're allowed, the most powerful tool in SRE.
Relaxed quorum rules that prioritize availability over strict replica placement.
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 SLO (Service Level Objectives)pay once,
yours for life
An SLO is a target value for a Service Level Indicator (SLI). The SLI is the raw measurement, like the fraction of HTTP requests that return a 2xx or 3xx status, or the fraction of requests served faster than 300ms. The SLO is the line you draw on that measurement: "this number should stay at or above 99.9% over the last 28 days."
Three things sit close together and get confused. An SLI is what you measure. An SLO is the internal target for that SLI. An SLA (Service Level Agreement) is a contract with a customer that usually promises a weaker number than your SLO, with money or credits on the line if you miss it. A common pattern is an SLA of 99.9% backed by an internal SLO of 99.95%, so you have headroom before you ever breach the contract.
The key idea is that 100% is the wrong target. Chasing perfect uptime is infinitely expensive and stops you shipping features. An SLO names the actual reliability your users need and lets you stop there on purpose.
The number behind an SLO directly produces an error budget. If your availability SLO is 99.9% over 30 days, you are allowed to be unavailable for 0.1% of that window, which is about 43 minutes per month. That 0.1% is the budget you get to spend on bugs, bad deploys, and risky experiments.
You compute the SLI continuously, usually from request logs or metrics in Prometheus, Datadog, or a similar system. For an availability SLO that is good_requests / total_requests. You then track how much of the error budget is left. Burning the budget slowly is fine. Burning it fast, say half the month's budget in one hour, should page someone.
Teams use multi-window, multi-burn-rate alerts so they page on real problems instead of on every single failed request. A fast burn rate triggers an urgent page, a slow steady burn opens a ticket. This is how Google's SRE practice ties alerting to user-facing impact rather than to arbitrary CPU or memory thresholds.
Use SLOs when more than one team depends on a service and you need a shared, honest definition of "healthy." They are most useful as the deciding vote in the feature-versus-reliability argument: if the error budget is healthy, ship faster and take risks. If the budget is exhausted, freeze risky changes and spend the next sprint on stability. That removes opinion from the conversation and replaces it with a number.
The trade-offs are real. A bad SLI measures the wrong thing, so a service can hit 99.9% on paper while users are unhappy. Setting the target too high wastes engineering effort on reliability nobody asked for; setting it too low erodes trust. SLOs also need ongoing care: you must agree on the measurement window, pick which requests count, and revisit the target as traffic and expectations change.
Start with one or two SLOs per critical user journey, like "checkout completes" or "search returns results," not a dashboard of fifty metrics. Measure from the user's edge where you can, since a backend that is 99.99% healthy means little if the load balancer in front of it is dropping requests.
Say you run a payments API. You define one SLI as the fraction of POST /charge requests that return a success status, and a second as the fraction that complete within 500ms. You set an availability SLO of 99.95% and a latency SLO of 99% under 500ms, both over a rolling 28 days.
99.95% availability over 28 days gives you roughly 20 minutes of allowed downtime. A bad deploy that returns 500s for 8 minutes spends about 40% of the month's budget in one shot. Your burn-rate alert fires, the on-call engineer rolls back, and because you still have budget left, you keep shipping. If a second incident eats the rest of the budget, the team triggers a change freeze until the window rolls forward and the budget refills.
Over months this gives you a fair, data-driven record of whether the service met its promise, and a clear signal for when to invest in reliability versus when to keep building.
Originated the SLI/SLO/error-budget model in its Site Reliability Engineering practice, where error budgets gate how fast product teams can ship.
Prometheus and Grafana
Open-source stack widely used to compute SLIs from request metrics and visualize SLO compliance and remaining error budget over time.
Datadog
Provides built-in SLO tracking that turns monitors and metrics into availability and latency objectives with burn-rate alerts.
Nobl9
A commercial platform dedicated to defining, calculating, and reporting SLOs across data sources like Prometheus, Datadog, and CloudWatch.
An SLO is your internal reliability target, like 99.95% availability. An SLA is a contract with customers that promises a number, usually weaker than your SLO, and attaches penalties such as service credits when you miss it. You set the SLO tighter so you get warning before you breach the SLA.
It is the amount of unreliability your SLO permits. A 99.9% monthly availability SLO allows 0.1% downtime, about 43 minutes per month. That 43 minutes is the budget you spend on deploys, experiments, and incidents before you have to slow down and stabilize.
100% is effectively impossible and absurdly expensive, and most users cannot tell the difference between 99.9% and 100% because their own network and devices fail more often than that. An SLO names the reliability users actually need so you stop spending money past the point of diminishing returns.
Start with one or two per critical user journey, typically an availability SLO and a latency SLO. Too many objectives dilute attention and create noise. Focus on the few signals that map directly to whether users are getting what they came for.
A rolling 28 or 30 day window is the common choice. It is long enough to smooth out single incidents and short enough that the error budget refills at a meaningful pace. Shorter windows make alerts twitchy; much longer windows hide ongoing degradation.
SLA/SLO/SLI Overview
Putting it all together, how SLIs, SLOs, and SLAs work as a unified reliability framework
Error Budget
The quantified amount of unreliability you're allowed, the most powerful tool in SRE
Sloppy Quorum
Relaxed quorum rules that prioritize availability over strict replica placement
SLO Engineering
Define and measure Service Level Objectives, the practice that aligns reliability with business needs
Quorum in Distributed Systems
What is quorum in system design? How read and write quorums work, why R + W > N, sloppy quorums, hinted handoff and quorum vs consensus, with a lab.
SLI
Service Level Indicator: a quantitative measure of service behavior, like the proportion of requests faster than 300ms. The raw metric that feeds SLOs.
SLA
Service Level Agreement: a contractual commitment between provider and customer specifying uptime, response time, and penalties for breaches. The business version of an SLO.
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.
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.
MTTR
Mean Time To Recovery: the average time from when a failure is detected to when the service is restored. A key reliability metric that drives investment in automation and runbooks.
This page explains the idea. The "SLO (Service Level Objectives)" 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 SLO (Service Level Objectives) lessoncourse 1
From absolute beginner to principal engineer, drawn step by step.
Asked about SLO 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.
