SLIs, SLOs, and SLAs

---

1 - Overview

Term	Definition	Example
SLI	A metric that measures the service	P99 latency
SLO	A target objective for the SLI	P99 < 200ms
SLA	A contract with consequences	99.9% with penalties

---

2 - Service Level Indicators (SLIs)

2.1 Characteristics of a good SLI

good_sli:
  - Quantitatively measurable
  - Reflects the user experience
  - Comparable over time
  - Simple to understand
  - Actionable

2.2 Types of SLIs

Category	SLI	Formula
Availability	Uptime	Successful requests / Total requests
Latency	Response time	Requests < threshold / Total requests
Throughput	Requests/sec	Successful requests / Time period
Error Rate	Errors	Failed requests / Total requests
Quality	Correctness	Correct responses / Total responses

2.3 SLI Specification

# sli-specification.yaml
slis:
  - name: availability
    description: "Proportion of successful HTTP requests"
    specification:
      type: ratio
      good_events: "HTTP 2xx responses"
      total_events: "All HTTP responses excluding 4xx"
    measurement:
      source: prometheus
      query: |
        sum(rate(http_requests_total{status=~"2.."}[5m]))
        /
        sum(rate(http_requests_total{status!~"4.."}[5m]))

  - name: latency
    description: "Proportion of requests served within 200ms"
    specification:
      type: ratio
      good_events: "Requests with latency < 200ms"
      total_events: "All requests"
    measurement:
      source: prometheus
      query: |
        sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
        /
        sum(rate(http_request_duration_seconds_count[5m]))

2.4 Request-based vs Window-based

request_based:
  # Each request counts individually
  formula: "Good requests / Total requests"
  example: "99.9% of requests succeeded"
  
window_based:
  # Time periods
  formula: "Good time windows / Total time windows"
  example: "99.9% of minutes with < 1% errors"

---

3 - Service Level Objectives (SLOs)

3.1 Defining an SLO

slo_definition:
  service: api-gateway
  sli: availability
  objective: 99.9%
  window: 30 days (rolling)
  
  # What it means
  allowed_downtime:
    per_day: 1.44 minutes
    per_week: 10.08 minutes
    per_month: 43.8 minutes
    per_year: 8.76 hours

3.2 Reliability levels

SLO	Downtime/year	Usage
99%	3.65 days	Internal tools
99.9%	8.76 hours	Standard services
99.95%	4.38 hours	Business critical
99.99%	52.6 minutes	Mission critical
99.999%	5.26 minutes	Life critical

3.3 Multi-SLO Strategy

# Multiple SLOs for a service
service: payment-api
slos:
  - name: availability
    objective: 99.95%
    window: 30d
    priority: P1
    
  - name: latency-p50
    objective: 95%  # 95% of requests < 100ms
    threshold: 100ms
    window: 30d
    priority: P2
    
  - name: latency-p99
    objective: 99%  # 99% of requests < 500ms
    threshold: 500ms
    window: 30d
    priority: P1

3.4 SLO Document

# slo-document.yaml
service: checkout-service
team: platform
owner: sre-[email protected]

description: |
  Checkout service for customer orders.
  Business critical.

slos:
  availability:
    sli: "Ratio of successful checkouts"
    objective: 99.9%
    window: 30 days rolling
    rationale: "Below this, revenue impact is significant"
    
  latency:
    sli: "P99 checkout completion time"
    objective: 99% < 3s
    window: 30 days rolling
    rationale: "User experience degrades above 3s"

error_budget_policy:
  document: link-to-policy
  
escalation:
  - severity: warning
    threshold: 50% budget consumed
    action: "Notify team"
  - severity: critical
    threshold: 75% budget consumed
    action: "Freeze non-critical changes"
  - severity: emergency
    threshold: 100% budget consumed
    action: "All hands on deck"

---

4 - Service Level Agreements (SLAs)

4.1 SLA vs SLO

Rule: The SLO must be stricter than the SLA (safety buffer).

4.2 Components of an SLA

sla_components:
  service_description:
    - What is covered
    - What is excluded
    
  availability_commitment:
    target: 99.9%
    measurement_period: Monthly
    
  performance_targets:
    - Response time commitments
    - Throughput guarantees
    
  remedies:
    - Service credits
    - Refunds
    - Termination rights
    
  exclusions:
    - Scheduled maintenance
    - Customer-caused issues
    - Force majeure

4.3 Example credit calculation

Availability	Credit
99.9% - 99.0%	10%
99.0% - 95.0%	25%
< 95.0%	50%

---

5 - Prometheus Implementation

5.1 Recording Rules

# recording-rules.yaml
groups:
  - name: slo_rules
    interval: 30s
    rules:
      # Availability SLI
      - record: sli:availability:ratio
        expr: |
          sum(rate(http_requests_total{status=~"2.."}[5m]))
          /
          sum(rate(http_requests_total{status!~"4.."}[5m]))

      # Latency SLI
      - record: sli:latency:ratio
        expr: |
          sum(rate(http_request_duration_seconds_bucket{le="0.2"}[5m]))
          /
          sum(rate(http_request_duration_seconds_count[5m]))

      # Error budget remaining (30 day window)
      - record: slo:error_budget:remaining
        expr: |
          1 - (
            (1 - sli:availability:ratio)
            /
            (1 - 0.999)  # SLO target
          )

5.2 Alerting Rules

groups:
  - name: slo_alerts
    rules:
      - alert: SLOBudgetBurnRateHigh
        expr: |
          (
            sli:availability:ratio < 0.999  # SLO
            and
            slo:error_budget:remaining < 0.5  # 50% remaining
          )
        for: 5m
        labels:
          severity: warning
        annotations:
          summary: "Error budget consumption rate is high"
          
      - alert: SLOBreached
        expr: slo:error_budget:remaining < 0
        for: 1m
        labels:
          severity: critical
        annotations:
          summary: "SLO has been breached"

---

6 - SLO Dashboard

6.1 Essential metrics

dashboard_panels:
  - title: "Current SLI"
    type: gauge
    query: sli:availability:ratio
    thresholds: [0.99, 0.999, 0.9999]
    
  - title: "Error Budget Remaining"
    type: stat
    query: slo:error_budget:remaining * 100
    unit: percent
    
  - title: "Error Budget Burn Rate"
    type: timeseries
    query: deriv(slo:error_budget:remaining[1h])
    
  - title: "Time Until Budget Exhaustion"
    type: stat
    query: |
      slo:error_budget:remaining 
      / 
      deriv(slo:error_budget:remaining[1h])

6.2 Burn Rate Windows

# Multi-window burn rate alerting
burn_rates:
  - window: 1h
    burn_rate: 14.4  # Exhaust budget in ~2 days
    severity: page
    
  - window: 6h
    burn_rate: 6  # Exhaust budget in ~5 days
    severity: page
    
  - window: 3d
    burn_rate: 1  # On track to exhaust budget
    severity: ticket

---

Summary

In this chapter, we learned:

• SLIs: the metrics that matter
• SLOs: internal objectives
• SLAs: customer commitments
• Implementation with Prometheus
• SLO dashboards
• Burn rates for alerting

---

Next step

In the next chapter, we will look at Error Budget.

→ Next chapter: Error Budget

---

← Back to table of contents