SLOs vs SLAs

System Design FundamentalsSeniorsystem-design

The Question

What is the difference between SLOs and SLAs?

What a Strong Answer Covers

• SLO = internal
• "SLA = contract with penalties

Senior-Level Answer

SLOs, SLAs, and SLIs form a hierarchy for defining, measuring, and committing to reliability. Understanding how they relate is central to site reliability engineering.

An **SLI (Service Level Indicator)** is the raw measurement — the actual metric that tells you how the system is behaving. Examples: request success rate (successful requests / total requests), request latency at the 99th percentile, data freshness, availability uptime. An SLI must be precisely defined: which requests count as 'successful'? 5xx errors only, or also timeouts? This precision matters because SLOs are built on SLIs.

An **SLO (Service Level Objective)** is an internal target: a threshold on an SLI that the engineering team commits to meeting. For example: "99.9% of HTTP requests will succeed over a 30-day rolling window" or "p99 latency will be below 200ms." SLOs are owned by engineering. They are not disclosed to customers — they are the operational targets that, if met, give confidence the SLA will not be breached. SLOs should be set *tighter* than SLAs to leave a safety margin.

An **SLA (Service Level Agreement)** is a contract between a service provider and a customer. It typically specifies both the reliability commitment (often weaker than the internal SLO — e.g., 99.5% uptime) and the consequences of breach (service credits, refunds, contract penalties). SLAs are negotiated by business and legal teams, not engineering alone. Breaching an SLA has financial and reputational consequences.

The critical operational concept built on SLOs is the **error budget**: if the SLO is 99.9% availability, the error budget is 0.1% of request failures — equivalent to ~43 minutes of downtime per 30-day window. The error budget is consumed by outages, slow deployments, and risky changes. When the error budget is depleted, engineering must stop feature work and focus on reliability improvements. When the budget is healthy, engineering can move faster and take more risk. This creates an objective, data-driven framework for balancing reliability investment against feature velocity.

A common failure mode is setting SLOs aspirationally rather than empirically — start by measuring your current SLI baseline and set the initial SLO slightly below it, then tighten as reliability improves.

Key Differences

What Separates a 2/3 from a 3/3

Common Mistakes

• Conflating SLO and SLA — the SLO is an internal engineering target, not a customer commitment.
• Not knowing what an error budget is or how it drives deployment frequency decisions.
• Defining availability as 'uptime' without specifying what counts as 'up' — a precise SLI definition matters.
• Setting SLOs equal to SLAs with no safety margin, making any SLO breach immediately a contractual violation.

Follow-Up Questions

• How would you calculate the error budget for a 99.9% availability SLO over a 30-day window? — 0.1% of 30 days × 24h × 60min = 43.2 minutes of allowed downtime. Budget expressed in minutes, or as request failure count if traffic volume is known.
• What should an engineering team do when an error budget is fully consumed? — Freeze risky feature deployments, focus sprint capacity on reliability work, postmortem recent incidents, and revisit whether the SLO is appropriately set.
• What is the difference between availability as a ratio and availability as latency-weighted? — Ratio counts successful/total requests. Latency-weighted (or latency SLO) counts requests served under a threshold — a slow response can be as harmful as an error for user experience.
• How would you handle a multi-tier service where each tier has its own SLO — how do you compute the composite availability? — For services in series, multiply availabilities: 99.9% × 99.9% = 99.8%. For redundant parallel paths, use 1 - (product of failure probabilities).

Related Questions

• Redis Caching Patterns
• Vertical vs Horizontal Scaling
• API Versioning
• Availability — Five 9s
• Latency vs Throughput