SLA, SLO and SLI — Dev Helper Library

Intent

SLI, SLO, and SLA form a hierarchy for turning "the system should be reliable" into measurable metrics, defensible targets, and enforceable contracts. Each layer has a different audience and different consequences in case of violation.

The framework was popularized by Google's Site Reliability Engineering (SRE) model and is now standard among teams that operate production systems with on-call. The core idea is that reliability needs to be defined before it can be measured, and measured before it can be negotiated. Without this chain, discussions about availability are subjective and engineering decisions lack objective criteria.

Problem

Engineering teams constantly face decisions about what to prioritize: new features or stability? Deploy now or wait for more testing? Scale the database or accept degradation? Without a clear definition of how much failure is acceptable, these decisions depend on intuition, internal politics, or the pressure of the moment:

Without an SLI: there's no consensus on what to measure. "The system is up" can mean the server responds to ping while 30% of requests return a 500 error. Infrastructure metrics don't reflect the real user experience.
Without an SLO: there's no target to defend. Any level of failure is implicitly acceptable, which leads to progressively more unstable systems without anyone formalizing the problem.
Without an SLA: there are no formal consequences for the service provider. Users and customers have no basis to demand compensation or escalate reliability problems.
Without an Error Budget: the decision to make a risky deploy or not is based on "it seems ok" instead of "we have X% of budget left this month." The budget concept turns reliability into a manageable resource.

How it works

SLI — Service Level Indicator

The SLI is the actual measured metric: a number that quantifies an aspect of the system's behavior from the user's point of view. It's the foundation of everything — SLO and SLA are expressions of SLIs.

Availability: proportion of successful requests / total requests.
Latency: proportion of requests answered in under X ms.
Error rate: proportion of 5xx responses / total responses.
Throughput: volume of operations processed per unit of time.

Choosing the SLI is critical: it must reflect the user's experience, not the infrastructure's health. The server can be "up" (5% CPU, memory fine) while the service returns timeouts to users. The right SLI captures what the user experiences, not what the infrastructure dashboard shows.

SLO — Service Level Objective

The SLO is the internal target for the SLI: the goal the engineering team commits to reaching and defends operationally. It's defined as a target value of the SLI over a time window.

Examples:

99.9% of requests with latency below 200ms over the last 30 days.
Availability of 99.95% measured as the proportion of successful requests in the calendar month.
Error rate below 0.1% in any 1-hour window.

The SLO is an internal target — it isn't the contract with the customer, but it's what engineering treats as the limit. When the SLO is being violated, that's the signal to page on-call, freeze deploys, and prioritize stability over features.

SLA — Service Level Agreement

The SLA is the external contract with the customer or user. It's based on the SLOs, but with a safety margin: the SLA is less strict than the internal SLO, because the team needs room to miss the SLO without immediately violating the contract.

Violating the SLA has formal consequences: invoice credits, contractual penalties, right of termination. That's why the SLA is always more permissive: if the internal SLO is 99.9%, the external SLA might be 99.5%.

Hierarchy and margins

  SLI (actual measurement)
  ──────────────────────────────────────────────────────────────────
  │  What the system is doing: proportion of successful requests
  │  measured over the last 30 days = 99.94%
  ▼

  SLO (internal target — what engineering defends)
  ──────────────────────────────────────────────────────────────────
  │  Target: SLI ≥ 99.9%
  │  Status: OK (99.94% > 99.9%)
  │  If violated → on-call alert, freeze on risky deploys
  ▼

  SLA (external contract — what the customer can demand)
  ──────────────────────────────────────────────────────────────────
  │  Contract: availability ≥ 99.5%
  │  Status: OK (99.94% >> 99.5%)
  │  If violated → credits, penalties, right of termination

  Safety margin: SLO (99.9%) - SLA (99.5%) = 0.4%
  Allows the SLO to be violated without immediately violating the contract.

Error Budget

The Error Budget is derived directly from the SLO: Error Budget = 1 - SLO. If the SLO is 99.9%, the monthly error budget is 0.1% of the time — roughly 43 minutes of downtime (or the equivalent proportion of failed requests). It's how much the system can fail within the period without violating the SLO.

The budget works like a resource: when it's full, the team has freedom to deploy new features with controlled risk. When it's near zero or exhausted, the policy is to freeze risky deploys and focus on stability until the budget renews. This makes the technical decision — "do we deploy now?" — depend on an objective data point instead of a subjective discussion.

Table of "nines" of availability

 Availability│ Downtime/year │ Downtime/month │ Downtime/week
─────────────┼───────────────┼────────────────┼───────────────
 99%         │ ~87.6 hours   │ ~7.3 hours     │ ~1.7 hours
 99.9%       │ ~8.7 hours    │ ~43.8 minutes  │ ~10.1 minutes
 99.99%      │ ~52.6 minutes │ ~4.4 minutes   │ ~1.0 minute
 99.999%     │ ~5.3 minutes  │ ~26.3 seconds  │ ~6.1 seconds
 99.9999%    │ ~31.5 seconds │ ~2.6 seconds   │ ~0.6 second

  Each additional "nine" reduces allowed downtime by ~10x and typically
  requires more complex and expensive architecture to reach consistently.

When to use

Any service with external users or real internal dependents: APIs consumed by other teams, B2B products, platforms with contractual SLAs. Without defined SLI/SLO, there's no criteria to know if the system is good enough.
Teams with on-call: the SLO is the objective criterion that defines when to page on-call and when things are back to normal. Without it, every engineer has their own definition of "problem."
Teams that need to balance speed and stability: the Error Budget is the technical arbiter. When the budget is full, the team can be more aggressive with deploys. When it's exhausted, the focus shifts to reliability.
B2B contracts with penalties: a formal SLA with consequences requires a more restrictive internal SLO and a well-defined SLI to continuously monitor.

When to avoid

Internal dev/test systems with no production impact: development environments, CI pipelines, low-criticality internal tools. The overhead of defining and monitoring SLOs doesn't pay off.
MVPs in the discovery phase: when the product is still being validated and the priority is fast learning, defining formal SLOs can create unnecessary rigidity. Introduce SLOs when the product starts having users with real reliability expectations.

Pros and cons

Pros

Common language: SLI/SLO/SLA create a shared vocabulary between engineering, product, and business to discuss reliability precisely.
Data-driven decisions: the Error Budget turns "do we deploy?" into a question with an objective answer based on real metrics.
Aligned expectations: the SLA makes explicit what the customer can expect and what happens if the expectation isn't met.
Clear prioritization: when the Error Budget is exhausted, the whole organization knows stability is the priority — no case-by-case negotiation.
Detects invisible problems: a well-chosen SLI captures degradation that infrastructure dashboards don't show.

Cons

Setup cost: defining relevant SLIs, implementing instrumentation, and building SLO dashboards requires non-trivial upfront investment.
SLI is hard to choose: measuring the right metric that reflects the user experience is more complex than it looks. Bad SLIs lead to SLOs that protect no one.
False precision: SLOs of 99.95% suggest a precision that may not exist if SLI measurement has errors or gaps.
Bureaucracy if misapplied: small teams with rigid SLOs and excessive deploy-freeze processes lose agility without proportional reliability gains.

Common pitfalls

1. SLO equal to the SLA

When the internal SLO and the external SLA are identical, there's no safety margin. Any incident that violates the SLO immediately violates the customer contract. The internal SLO should be more restrictive than the external SLA to absorb incidents before they reach the level of a contractual penalty.

2. SLI that doesn't reflect the user experience

Measuring server uptime (does ping respond?) instead of service availability (are requests succeeding?) is the most common mistake. The server can be "up," returning a 200 status with an error body for every request. The SLI should measure what the user experiences, not what the infrastructure reports.

Rule of thumb: if a user can perceive the degradation but the SLI doesn't indicate a problem, the SLI is wrong. The question is: "can the user do what they need to?" — and the SLI should answer that.

3. Error Budget ignored in practice

Many teams define an SLO and calculate the Error Budget but don't change behavior when the budget runs out. Risky deploys continue, new features keep shipping to production, and the SLO becomes a decorative metric. The Error Budget's value is behavioral: it needs to change real decisions, or it exists for nothing.

4. SLO too aggressive from the start

Defining 99.999% availability as the SLO for a new service requires expensive, complex high-availability architecture — redundancy across multiple data centers, automatic failover, chaos testing, etc. Start with 99.9%, measure the real SLI for a few months, and adjust the SLO based on the data. SLOs should be calibrated to the system's reality, not to aspirations.

Related architectures and patterns

Circuit Breaker and SLO operate at different layers of the same goal. The SLO defines the reliability level the system should reach (e.g., 99.9% successful requests). The Circuit Breaker is a mechanism that helps reach that goal by preventing cascading failures and gracefully degrading the service instead of failing completely. The circuit's state — how many times it opened, for how long — is a direct data point for the availability SLI.

Load Balancing and Horizontal Scalability are operational mechanisms that increase the capacity to maintain the SLO. Scaling horizontally distributes load, reducing the risk of overload that degrades the SLI. The Load Balancer detects failing instances and removes them from the pool, maintaining the availability measured by the SLI even when individual instances fail.