# SLIs, SLOs and SLAs > An SLI measures service behavior, an SLO sets a target for that measure, and an SLA defines a customer-facing commitment and consequences for missing it. In system design interviews, they turn vague requirements like “high availability” into concrete decisions about redundancy, latency, capacity, and failure handling. Source: https://sysround.com/concepts/sli-slo-sla Updated: 2026-11-05 ## How slis, slos and slas works Start with a user-visible outcome and define a service-level indicator (SLI). For an API, this might be successful requests divided by eligible requests; for a scheduler, it might be jobs started within 30 seconds of their scheduled time divided by eligible scheduled jobs. CPU usage helps diagnose problems, but it does not directly measure whether users received the service. Set a service-level objective (SLO): a target for the SLI over a stated window. For example, “99.9% of eligible requests succeed over a rolling 30-day window” is an availability SLO. A separate latency SLO might require 99% of eligible requests to complete successfully within 300 milliseconds. Specify the measurement boundary and eligibility rules. Decide whether timeouts, overload rejections, client errors, retries, and dependency failures count, and measure close enough to the user to capture failures that never reach an application server. For asynchronous work, measure completion or delivery delay rather than treating queue acceptance as the final outcome. A service-level agreement (SLA) is a customer-facing agreement that states a service commitment, its measurement rules, exclusions, and remedies such as service credits. An internal SLO is often stricter than the SLA commitment, leaving room to respond before breaching the agreement. Missing an SLO does not automatically mean an SLA was breached. Compute the error budget from the SLO: allowed bad fraction = 1 − target. A 99.9% request-based SLO allows 0.1% bad requests; with 10 million eligible requests, that is 10,000 bad requests. A request-based budget is not automatically a number of downtime minutes, because traffic varies over time. Use budget consumption to guide operations. Burn rate is the observed bad-event fraction divided by the allowed bad-event fraction; a sustained rate above 1 consumes the budget faster than the window permits. Alert on sustained fast consumption using short and long windows, and agree on actions such as pausing risky releases, rolling back, or prioritizing reliability work. ## Worked example: A scheduler with a start-time error budget Suppose a job scheduler must start 99.9% of eligible scheduled jobs within 30 seconds over a rolling 30-day window. Measure each occurrence from its scheduled time until a worker actually starts it; a dispatch acknowledgment alone does not count. If the window contains 10 million occurrences, the allowed budget is 10,000 late or missed starts. A worker outage that makes 2,000 occurrences late consumes 20% of that budget. This target motivates durable occurrence creation, spare worker capacity, and backlog monitoring. Alert on elevated late-start rates before the budget is exhausted. Define maintenance and cancellation rules explicitly, and track execution success separately: starting on time does not mean the job completed correctly. ## Trade-offs - **Higher targets require stronger failure handling.** Tighter SLOs can require more spare capacity, redundancy, dependency isolation, and operational work, so justify them using user impact rather than choosing more nines by default. - **Aggregate success can hide localized failures.** A global SLI may pass while one region or customer group has a serious outage, so add targeted breakdowns without creating unbounded metric cardinality. - **Measurement fidelity has a cost.** Client-side measurements capture failures invisible to servers but introduce reporting gaps, sampling questions, and additional instrumentation. - **Dependencies constrain achievable reliability.** A critical synchronous dependency can prevent you from meeting your target unless you add a fallback, remove it from the critical path, or improve its reliability. - **Window choice changes the response.** Short windows react quickly but fluctuate more, while long windows smooth noise and need burn-rate alerts to expose rapidly growing problems. - **Error budgets need an agreed policy.** Without predefined responses to budget exhaustion, the budget becomes a dashboard number rather than a way to balance reliability work and feature delivery. ## When to use it in a system design interview - The interviewer asks for high availability, low latency, or real-time behavior without specifying a measurable target. - You need to justify the cost of replicas, spare capacity, regional failover, or dependency isolation. - An asynchronous workflow needs a delivery, freshness, or start-time deadline rather than just an API availability target. - The discussion reaches production monitoring, alerting, safe releases, or what happens when reliability degrades. ## How to bring it up in the interview - Propose a concrete target and confirm it: “Should we aim for 99.9% successful requests over 30 days, with a separate latency target?” Present the number as an assumption, not a universal standard. - Define the denominator and measurement boundary before discussing architecture; expect questions about retries, timeouts, overload rejections, missing telemetry, and failures before the service receives a request. - Translate the target into a budget and explain which failures consume it; distinguish request-based budgets from time-based availability. - Connect design choices to the target: explain how failover duration, queue backlog, deployment failures, or dependency outages affect user-visible success. - Explain how you would detect fast budget burn and respond; expect follow-ups about alert noise, release restrictions, and whether a healthy global metric hides a regional outage. ## Common mistakes - Using SLI, SLO, and SLA interchangeably instead of distinguishing measurement, target, and agreement. - Choosing 99.999% availability without discussing user needs, dependency limits, cost, or recovery time. - Using average latency or server uptime as the only measure of user experience. - Excluding overload failures or counting queue acceptance as successful delivery just to make the metric look healthy. - Treating an error budget as permission for planned outages or converting request failures directly into downtime minutes. ## Interview questions where it comes up - [Design a metrics monitoring system like Datadog](https://sysround.com/questions/design-metrics-monitoring-system): SLI calculations and budget-burn alerts require correct aggregation and explicit handling of missing data so outages do not appear healthy. - [Design a distributed job scheduler](https://sysround.com/questions/design-job-scheduler): A start-time SLO defines acceptable dispatch delay and drives capacity planning, backlog handling, and recovery after cron bursts. - [Design an on-call escalation system like PagerDuty](https://sysround.com/questions/design-pagerduty): Acknowledgment and notification timing targets require measurable outcomes that distinguish durable scheduling from uncertain provider delivery. ## FAQ ### What is the difference between an SLI, an SLO, and an SLA? An SLI is a measured indicator, such as the fraction of requests that succeed. An SLO is the desired target over a defined window. An SLA is a customer-facing agreement that specifies commitments and consequences for failing to meet them. ### How do you calculate an error budget? Subtract the SLO target from 100% to get the allowed bad-event percentage. For a 99.9% request-based target and 10 million eligible requests, the budget is 10,000 bad requests. For a time-based availability target, 99.9% over exactly 30 days permits 43.2 minutes of unavailability; these two measurement models are not interchangeable. ### What is error budget burn rate? Burn rate is the observed bad-event fraction divided by the fraction the SLO allows. With a 99.9% SLO, a 1% failure rate is a burn rate of 10. Alerts commonly combine short and long evaluation windows to detect sustained fast consumption without paging on every brief spike. ## Related concepts - [Observability](https://sysround.com/concepts/observability) - [Failover](https://sysround.com/concepts/failover) - [Load shedding](https://sysround.com/concepts/load-shedding) - [Canary deployment](https://sysround.com/concepts/canary-deployment) --- SysRound (https://sysround.com) is an AI practice tool for system design interviews: a voice or typed AI interviewer, a shared whiteboard, then feedback on every skill and a model answer. Its feedback is AI-generated and can be wrong.