Skip to main content
When designing a system or application, teams should set specific, measurable targets to balance product development and operations. These targets let customers and stakeholders understand the reliability they can expect — for example, “the application should maintain 97% uptime over a rolling 30-day window.” This guide defines the three core concepts used in reliability engineering and site reliability practices, explains how to choose good indicators, and shows how to apply targets and contracts to manage risk and product velocity.

​
What is an SLI (Service Level Indicator)?

An SLI is a quantitative metric that measures a particular aspect of the level of service delivered to users. SLIs should reflect the actual user experience whenever possible so they track what matters. Common SLIs:
  • Request latency (e.g., p95, p99)
  • Error rate (e.g., % of failed requests)
  • Throughput / saturation (requests per second, queue length)
  • Availability (percent uptime)
A presentation slide titled "Service Level Indicator" that defines an SLI as a quantitative measure of some aspect of provided service. It also lists common SLIs: request latency, error rate, saturation, throughput, and availability.
Tips for choosing SLIs:
  • Prefer user-centric metrics (latency and error rate) over internal resource metrics.
  • Make sure SLIs are measurable, reproducible, and meaningful to stakeholders.
  • Avoid SLIs that are easy to measure but don’t correlate with user impact (e.g., CPU or memory usage alone).
An infographic slide titled "Service Level indicator" explaining that not all metrics make good SLIs and you should measure the user's experience. It shows a user saying "Everything looks good to me" while a server box reports "Experiencing High CPU" as an example.

​
What is an SLO (Service Level Objective)?

An SLO is a target or acceptable range for an SLI — a concrete reliability goal your team commits to hit. SLOs translate metrics into actionable objectives tied to user experience. Examples:
  • Latency SLO: p95 request latency < 100 ms.
  • Availability SLO: 99.9% uptime over a rolling 30-day window.
SLOs should be realistic and aligned with customer expectations. They’re used to make trade-offs between developer velocity, engineering cost, and user satisfaction.
A dark slide titled "Service Level Object" explaining that an SLO is a target for an SLI, with examples: latency SLO < 100ms and availability SLO of 99.9% uptime.
Be careful not to set SLOs to unattainable or unnecessarily aggressive values (for example, 100% uptime). Achieving higher reliability typically requires substantially more engineering effort and cost. The goal of an SLO is to choose a level of reliability that keeps customers satisfied while enabling sustainable operations and product development.
Use an error budget to operationalize SLOs: error budget = (1 − SLO). Teams can spend the error budget on releases, feature changes, and experiments. If the budget is exhausted, shift focus to reliability work until the budget is restored.
A presentation slide titled "SLO" explaining that setting SLOs to aggressive values like 100% uptime is costly. It says the goal is to satisfy customers with the right level of reliability — if customers are happy with 99% reliability, increasing it further adds no value.

​
What is an SLA (Service Level Agreement)?

An SLA is a formal contract between a provider and a customer that guarantees a specific SLO. SLAs typically include legally binding terms and define consequences for failing to meet the agreed SLOs (for example, service credits, termination rights, or other remedies). Key points about SLAs:
  • SLAs formalize commitments to external customers.
  • They usually include measurement windows, reporting requirements, and remediation steps.
  • Violating an SLA can trigger contractual penalties.
A presentation slide titled "SLA" that defines a Service Level Agreement as a contract between a vendor and a user guaranteeing a certain SLO, with a handshake icon. It also states that failing to meet SLOs can result in financial or other consequences.

​
Quick comparison

​
Practical recommendations

  • Start with user-facing SLIs (latency, error rate, availability).
  • Define SLOs that balance customer expectations with sustainable engineering effort.
  • Use an error budget to make data-driven trade-offs between feature releases and reliability work.
  • Only export SLAs to customers after you understand the real cost and operational burden of meeting those targets.
In short:
  • SLI = measurable metric reflecting service quality.
  • SLO = target for an SLI that defines acceptable reliability.
  • SLA = contract that formalizes SLOs and associated consequences.
Choosing the right SLIs and SLOs helps balance customer satisfaction, operational cost, and product velocity.

Watch Video