SLIs, SLOs, and SLAs: Making Reliability Measurable and Contractual

Google's Error Budget Revolution

Before Google pioneered SRE, reliability was a vague goal: 'make it as reliable as possible.' This meant the ops team always wanted more testing and fewer deployments, while the dev team always wanted to ship faster. They were in permanent conflict. Google's insight was to make reliability a finite, measurable resource - an error budget - that both teams manage together. If the budget is full, ship features. If it is depleted, fix reliability. No more arguing.

SLI, SLO, SLA: The Hierarchy

The Three Levels:

  SLI (Service Level Indicator) - the MEASUREMENT
    What: a specific metric
    Example: 'the % of requests completing in < 500ms'
    Formula: (requests < 500ms) / (total requests) * 100

  SLO (Service Level Objective) - the TARGET
    What: the goal for an SLI over a time window
    Example: 'SLI >= 99.9% over rolling 30 days'
    Internal agreement between teams

  SLA (Service Level Agreement) - the CONTRACT
    What: SLO + consequences for missing it
    Example: 'If availability < 99.9%, customer gets
             10% service credit per 0.1% below target'
    External contract with customers.
    Usually set LOWER than internal SLOs.

  Relationship:
    SLA <= SLO (external promise <= internal target)
    SLO is based on SLI (target needs a measurement)
    If internal SLO is 99.95%, external SLA might be 99.9%

Error Budgets: The Key Insight

Error Budget Calculation:

  SLO: 99.9% availability over 30 days
  Error budget: 100% - 99.9% = 0.1%

  30 days = 43,200 minutes
  0.1% of 43,200 = 43.2 minutes of allowed downtime

  Error budget tracking:
  Day 1-10:  0 incidents       -> 43.2 min remaining (100%)
  Day 11:    5 min outage      -> 38.2 min remaining (88%)
  Day 15:    20 min degradation -> 18.2 min remaining (42%)
  Day 20:    Decision: FREEZE deployments?
             Budget at 42% with 10 days left.
             risky deploy could use remaining budget.

  Budget remaining   Action
  ----------------   ----------------------------------
  > 50%              Ship features, take risks
  25-50%             Ship carefully, extra testing
  10-25%             Bug fixes only, no new features
  < 10%              All hands on reliability work
  0%                 Deployment freeze until budget resets

Choosing Good SLIs

Good SLIs by Service Type:

Service Type      SLI                    Example Target
----------------  ---------------------  ---------------
API/Web service   Availability           99.9%
                  Latency (p99)          < 500ms
                  Error rate             < 0.1%

Data pipeline     Freshness              < 5 min old
                  Correctness            99.99%
                  Coverage               > 99.5% processed

Storage system    Durability             99.999999999%
                  Availability           99.99%
                  Read latency (p99)     < 10ms

Bad SLIs (do not use):
  - CPU usage (internal metric, not user-facing)
  - Uptime in hours (too coarse)
  - 'Number of incidents' (not measurable in real-time)

The Nines Table

Availability   Downtime/year   Downtime/month   Cost
-------------  --------------  ---------------  ----------
99%   (2 9s)   3.65 days       7.3 hours        Low
99.9% (3 9s)   8.76 hours      43.2 minutes     Moderate
99.95%         4.38 hours      21.6 minutes     High
99.99%(4 9s)   52.6 minutes    4.3 minutes      Very high
99.999%(5 9s)  5.26 minutes    25.9 seconds     Extreme

Most web services: 99.9% is a good starting point.
Each additional 9 roughly 10x the engineering cost.
99.999% requires: multi-region, automated failover,
  zero-downtime deploys, chaos engineering.

Interview Tip

When discussing reliability requirements, say: 'I would define SLIs based on user-facing metrics: availability (% of successful requests), latency (p99 < 500ms), and error rate (< 0.1%). I would set internal SLOs at 99.95% and external SLAs at 99.9%, giving us a buffer. The error budget (0.05% = ~21 minutes/month) becomes the decision framework: if budget is healthy, we ship features. If it is depleted, we freeze deployments and focus on reliability. This aligns dev and ops teams with a shared, measurable target.'

<

/blockquote>

Key Takeaway

SLIs measure reliability, SLOs set targets, SLAs make it contractual. Error budgets turn reliability from an abstract goal into a finite resource that engineering teams can make rational decisions with. If your error budget is full, ship features. If it is depleted, fix reliability.