We've explored SLIs, SLOs, and SLAs as individual concepts. Now it's time to understand how they function as an integrated system—a reliability framework where each component plays a distinct role, and their interactions create a coherent approach to managing and improving service reliability.

Think of it like a control system: SLIs are the sensors (what's happening), SLOs are the setpoints (what should happen), and SLAs are the contracts (what we've promised). The gaps between them create actionable signals that drive engineering behavior.

The relationship between SLIs, SLOs, and SLAs forms a clear hierarchy, each building upon the previous:

Level 1: SLI — The Foundation (Measurement)

SLIs answer: What is our current performance?

• They are raw measurements of service behavior
• They exist independently of any targets
• They should accurately reflect user experience
• Example: 99.4% of requests succeeded this week

Level 2: SLO — The Target (Internal Commitment)

SLOs answer: What performance level are we aiming for?

• They are targets set on top of SLIs
• They guide engineering prioritization
• They are internal—customers don't usually see them
• Example: We target 99.9% success rate

Level 3: SLA — The Contract (External Commitment)

SLAs answer: What performance level are we promising to customers?

• They are contractual commitments based on SLO capability
• They carry financial and legal consequences
• They are external—published to customers
• Example: We guarantee 99.5% and pay credits if we fail

The Buffer Zones

Buffer 1: SLI to SLO

When your SLI is below your SLO, you have a problem that needs fixing but haven't broken any promises yet. This is your early warning zone.

SLI = 99.85%
SLO = 99.9%
Gap = -0.05% → Action needed: investigate, prioritize fixes

Buffer 2: SLO to SLA

Even if you temporarily drop below your SLO, you may still be above your SLA, avoiding financial penalties.

SLI = 99.7%
SLO = 99.9% (missing!)
SLA = 99.5% (still safe)
Gap = +0.2% → Warning: you're in the danger zone

This buffer exists precisely to give you time to recover before contractual violations occur.

The SLI/SLO/SLA framework creates continuous feedback loops that drive operational and strategic decisions. Understanding these flows is essential for making the framework actionable.

Flow 1: Bottom-Up (Reality → Strategy)

SLI informs SLO adjustment:

If your SLI consistently exceeds your SLO by a wide margin, you might:

• Tighten the SLO (get more ambitious)
• Promise more in the SLA (competitive advantage)
• Reduce reliability investment (cost optimization)

If your SLI frequently misses your SLO:

• Investigate root causes
• Increase reliability investment
• Consider loosening SLA (if consistently at risk)

SLO informs SLA negotiation:

When sales asks 'Can we promise 99.99%?', the answer should be:

• Check SLO: What are we actually targeting?
• Check SLI history: Have we ever achieved 99.99%?
• Check dependencies: Can we theoretically achieve it?

Flow 2: Top-Down (Contracts → Engineering)

SLA drives SLO requirements:

If a critical customer signs an SLA requiring 99.99% availability:

• SLO must be set higher (at least 99.995%)
• Engineering must invest in infrastructure to hit this SLO
• Monitoring and alerting must be tuned for this target

SLA violations drive prioritization:

An SLA miss is a high-severity event that:

• Triggers post-mortem and root cause analysis
• May require executive-level communication
• Often justifies emergency investment in fixes
• Creates data for future SLO/SLA discussions

Error budgets are perhaps the most powerful concept that emerges from the SLI/SLO relationship. An error budget is the inverse of your SLO—it quantifies how much unreliability you can tolerate.

The error budget formula:

Error Budget = 100% - SLO

If SLO = 99.9%, Error Budget = 0.1%
Over 30 days: 0.1% of 30 days = 43.2 minutes of allowed downtime

The error budget creates a shared language between reliability work and feature velocity.

Error Budget Consumption

What spends error budget:

1. Outages and incidents — Unplanned downtime directly consumes budget
2. Elevated error rates — Even partial degradation counts
3. Latency degradation — If latency SLO is breached
4. Planned maintenance — Scheduled downtime also consumes budget

Tracking error budget burn:

28-day rolling window
SLO: 99.9%
Error budget: 0.1% = 40.32 minutes

Incidents this window:
- Jan 3: 12 minutes (30% of budget)
- Jan 15: 8 minutes (20% of budget)
- Planned maintenance: 5 minutes (12% of budget)

Total consumed: 25 minutes (62% of budget)
Remaining: 15.32 minutes (38% of budget)

Error Budget Policies

What happens when error budget is exhausted?

Mature organizations define policies:

When budget > 50% remaining:

• Normal feature development
• Regular deployment cadence
• Standard risk tolerance

When budget at 25-50%:

• Increased scrutiny on deployments
• Reliability work prioritized
• No risky experiments

When budget < 25%:

• Feature freeze considered
• All hands on reliability
• Deployment rollback threshold lowered

When budget exhausted:

• Feature development halts
• All engineering on reliability
• Leadership escalation

Different roles in the organization interact with SLIs, SLOs, and SLAs in different ways. Clarity on responsibilities prevents gaps and conflicts.

The Escalation Path

Level 1: Engineering Awareness

Trigger: SLI drops below SLO
Response: Team investigates, adds to sprint backlog
Owner: Service team lead

Level 2: Prioritization Escalation

Trigger: Error budget at 50%
Response: Reliability work prioritized over features
Owner: Engineering manager

Level 3: Leadership Escalation

Trigger: Error budget at 25%, SLA at risk
Response: Resource reallocation, potential feature freeze
Owner: Director/VP Engineering

Level 4: Executive Escalation

Trigger: SLA violation imminent or occurred
Response: Incident command, customer communication, credits
Owner: CTO/COO

The SLI/SLO/SLA framework isn't just for monthly reports—it should drive real-time operational decisions. Here's how mature organizations operationalize the framework:

SLO-Based Alerting

Traditional alerting (symptom-based):

Alert: CPU > 80% for 5 minutes
Problem: May or may not affect users
       Creates alert fatigue

SLO-based alerting (impact-based):

Alert: Error budget burn rate exceeds 14.4x (fast burn)
       If maintained, budget exhausted in 2 hours
Benefit: Alert only when users are impacted
         Prioritizes by actual severity

Burn rate alerting:

Burn rate measures how fast you're consuming error budget:

Burn rate = (Error rate over period) / (Error budget rate)

If SLO = 99.9%, error budget rate = 0.1%
If current error rate = 1.44%, burn rate = 1.44 / 0.1 = 14.4x

14.4x burn rate = budget exhausted in 28 days / 14.4 = 1.94 days

Multi-window alerting:

This approach pages only for urgent issues while still tracking slow degradation.

Deployment Decisions

Pre-deployment checklist:

1. Error budget status: Is there room for risk?
2. Rollback plan: Can we recover if SLI drops?
3. Monitoring: Are SLIs instrumented for the change?
4. Gradual rollout: Can we catch problems before 100% exposure?

Error budget gates:

if (errorBudgetRemaining < 10%):
    requireDirectorApproval()
    mandatoryCanaryDeploy()
    reduceBlastRadius()
else if (errorBudgetRemaining < 25%):
    requireTeamLeadApproval()
    recommendCanaryDeploy()
else:
    standardDeploymentProcess()

Incident Response

During incidents, the framework provides:

1. Impact quantification: 'We're burning error budget at 100x, budget exhausted in 7 hours'
2. Prioritization: SLO impact severity determines incident level
3. Communication: 'SLI at 95%, SLA threshold is 99.5%, we have margin'
4. Resolution criteria: 'Incident resolved when SLI returns above SLO'

Beyond daily operations, the SLI/SLO/SLA framework informs strategic planning and resource allocation.

Reliability Investment Justification

The traditional approach (weak):

'We should invest in redundancy because reliability is important.'
Problem: Vague, hard to prioritize, no ROI

The SLO-driven approach (strong):

'Our current SLI is 99.5%. Our SLO is 99.9%. We miss the SLO 4 months/year.
Each miss correlates with 15% increase in customer churn.
Investing $500K in multi-region redundancy will improve SLI to 99.95%,
reducing churn-related revenue loss by an estimated $2M/year.
ROI: 4x in year 1.'

Quantifying reliability value:

1. SLA credit savings: (Current violation rate × credit rate) × improvement factor
2. Churn reduction: (Users lost to reliability issues × LTV) × improvement factor
3. Support cost reduction: (Reliability-related tickets × cost/ticket) × improvement factor
4. Engineering efficiency: (Hours spent on incidents × hourly cost) × improvement factor

Capacity Planning

SLO-informed capacity planning:

Current state:
- Peak load: 10,000 RPS
- SLI at peak: 99.3% (failing SLO of 99.9%)

Projected growth:
- Expected peak in 6 months: 15,000 RPS
- Expected SLI at 15K RPS: ~98.5% (well below SLO)

Capacity requirement:
- Need infrastructure to serve 15K RPS at 99.9%+ SLI
- Based on testing, this requires X additional servers, Y database capacity
- Investment: $Z/month

Quarterly Reliability Review

Agenda for quarterly SLO review:

1. SLI/SLO achievement summary:

   • Which services met SLO?
   • Which missed and by how much?
   • Trend: improving or degrading?

2. Error budget analysis:

   • Budget consumption patterns
   • Root causes of major consumption events
   • Correlation with deployment activity

3. SLA compliance:

   • Any SLA violations?
   • Credit exposure?
   • Customer impact and communication?

4. Action items:

   • Reliability investments approved
   • SLO adjustments (tighter or looser)
   • SLA changes for next contract cycle

5. Forward-looking:

   • Expected load growth
   • Known reliability risks
   • Planned improvements

Even organizations that understand SLIs, SLOs, and SLAs individually often fail to integrate them effectively. Here are the most common failure modes and how to avoid them:

Case Study: The Misaligned SLA

Scenario:

A SaaS company's sales team offers a 99.99% SLA to win a major enterprise contract. Engineering has never been consulted.

Reality:

• Current SLI: 99.5% (average)
• Current SLO: None defined
• Dependencies: Payment provider at 99.9%, cloud infrastructure at 99.99%

Consequences:

• Theoretical max availability: ~99.89% (below SLA promise)
• Months 1-3: SLA violations, credits paid
• Month 4: Customer threatens contract termination
• Month 6: Emergency multi-region migration ($2M unplanned)
• Month 9: Finally achieving 99.95%, still below SLA
• Year 1 total: $1.5M in credits, $2M in emergency infra, customer retention uncertain

What should have happened:

• Sales asks: 'Can we promise 99.99%?'
• Engineering checks: 'Our SLO is 99.9%, with dependency ceiling at 99.89%'
• Answer: 'We can promise 99.5% now, or invest $X to reach 99.9% in 6 months'
• Negotiation: Customer accepts 99.9% SLA with roadmap to 99.99%

SLIs, SLOs, and SLAs are not three separate concepts—they are an integrated system where each component enables the others. Together, they create a coherent approach to reliability that spans measurement, targeting, and commitment.

What's next:

With the complete SLI/SLO/SLA framework understood, we need to explore how to align these commitments with business requirements—ensuring that reliability targets serve business objectives and that business understands the tradeoffs involved.