SLA, SLO and SLI compared

In the context of service reliability and performance management, SLA (Service Level Agreement), SLO (Service Level Objective), and SLI (Service Level Indicator) are key concepts used to define, measure, and enforce service quality. While they are closely related, each serves a distinct role in ensuring reliable and predictable service delivery.

1. Service Level Indicator (SLI)

An SLI is a quantitative measure of a system’s performance and reliability. It represents specific metrics that track service health, providing insight into how well a service is performing from an operational perspective.

Expanded Examples of SLIs:

• Availability SLI: The percentage of successful HTTP requests (e.g. returning 2xx, 3xx, or 4xx series responses, depending on whether user errors are excluded) over a given period.
• Latency SLI: The proportion of API requests served within a specific response time threshold (e.g., p95 latency under 150ms).
• Throughput SLI: The number of database read/write transactions successfully completed per second.
• Freshness SLI: The percentage of data records processed and loaded into an analytics warehouse within 10 minutes of generation.
• Quality SLI: The proportion of search queries returned with complete search results, rather than a degraded/cached fallback state.

SLIs are the raw data points and the foundation upon which objectives and agreements are built.

2. Service Level Objective (SLO)

An SLO is a target value or range for an SLI, defining an acceptable level of performance. It acts as an internal reliability benchmark for teams to maintain service quality before breaching contractual obligations.

Expanded Examples of SLOs:

• Availability SLO: Availability SLI is $\ge 99.9\%$ over a rolling 30-day window.
• Latency SLO: $95\%$ of successful API calls must have a Latency SLI of $< 200\text{ms}$ over any calendar month.
• Throughput SLO: Throughput SLI remains $\ge 1,000\text{ transactions per second}$ during core trading hours.
• Freshness SLO: Freshness SLI is $\ge 99\%$ over a 7-day rolling window.

The Error Budget

By setting an SLO (e.g., $99.9\%$), you define an Error Budget of $0.1\%$. This budget represents the allowable amount of unreliability, giving the engineering team room to deploy new features, perform updates, and take calculated risks. If the Error Budget is exhausted, focus shifts from feature delivery to stability.

3. Service Level Agreement (SLA)

An SLA is a formal contract between a service provider and its customers, specifying the promised level of service. It typically includes SLOs, along with consequences (such as refunds, service credits, or contract termination) if the provider fails to meet them.

Expanded Examples of SLAs:

• Availability SLA: A contractual guarantee of $\ge 99.9\%$ monthly uptime. If availability drops below $99.9\%$, the customer is entitled to a service credit equal to $10\%$ of their monthly invoice; if it drops below $99.0\%$, they receive a $30\%$ credit.
• Support Response SLA: A commitment to acknowledge critical P1 incidents within 15 minutes, with updates provided every 30 minutes until resolution.
• Data Durability SLA: A contractual guarantee of $99.999999999\%$ (11 nines) annual data durability, with direct financial compensation for any permanent data loss.

SLAs are legally binding, whereas SLOs are internal goals.

Comparison and Relationship

Strategic Utility for CTOs: Managing the Reliability Trade-Off

For a technology leader, SLA, SLO, and SLI management is not just a monitoring exercise—it is a critical tool for prioritisation and alignment:

1. Governing Prioritisation via Error Budgets: The Error Budget provides an objective decision-making framework. If the budget is healthy, the team can ship features rapidly. If the Error Budget is exhausted, the team shifts focus to reliability, technical debt, and performance optimisation.
2. Defending the Engineering Team: By aligning with product management on realistic, customer-focused SLOs, you prevent the business from demanding unachievable (and expensive) "$100\%$ availability" targets.
3. Protecting Against Financial Risk: Customer-facing SLAs should always be set with a safety margin (i.e. more lenient) compared to internal SLOs. If your internal SLO is $99.9\%$, your external SLA should be $99.0\%$ or $99.5\%$. This buffer gives your on-call engineers time to detect, diagnose, and resolve incidents before they incur legal or financial liabilities.
4. Fostering User-Centric Monitoring: Focus your SLIs on what the user actually experiences. A database server running at $95\%$ CPU utilisation is a poor SLI if users are still receiving fast, correct responses. Align indicators with user satisfaction to avoid alert fatigue.

Explore Next

• RTO and RPO — Understand the core concepts of Recovery Time Objective and Recovery Point Objective.
• DORA Metrics — Measure stability and velocity with the four key DevOps metrics.
• Technical Post-Mortems — Learn how to conduct blameless post-mortems when reliability targets are missed.

References

• Google SRE Book - Service Level Objectives — The definitive guide to defining and managing SLIs, SLOs, and Error Budgets.
• Wikipedia: Service level agreementWikipedia — Detailed overview of contractual service level agreements.