DEV Community

Vigilmon
Vigilmon

Posted on

SLA vs SLO vs SLI: What the Differences Actually Mean for Developers

#devops #sre #monitoring #webdev

SLA vs SLO vs SLI: What the Differences Actually Mean for Developers

If you've ever set up uptime monitoring and tried to figure out what numbers to track, you've probably run into three terms: SLA, SLO, and SLI. They sound similar and are frequently used interchangeably, but they serve very different purposes.

Here's the practical breakdown.

SLI — Service Level Indicator (The Measurement)

An SLI is a specific metric that measures how your service is performing. It is the raw number.

Common SLIs for web services:

  • Availability: percentage of successful HTTP requests in the last 30 days
  • Latency: percentage of requests completed under 200ms
  • Error rate: percentage of requests returning 5xx responses
  • Throughput: requests processed per second

An SLI answers: "What happened?"

Example: "Our availability SLI over the past 30 days is 99.72%."

SLO — Service Level Objective (The Target)

An SLO is the target value for an SLI. It is the internal goal your team sets and defends.

SLOs are owned by engineering teams. They define what "good enough" looks like.

Example SLOs:

  • Availability SLO: 99.9% uptime measured monthly
  • Latency SLO: 95% of requests complete under 300ms
  • Error rate SLO: < 0.1% 5xx responses per hour

SLOs answer: "What are we trying to achieve?"

Error budgets come from SLOs. If your SLO is 99.9% availability, your error budget is 0.1% — about 43 minutes of downtime per month. Once you've burned through that budget, you stop shipping new features and fix reliability instead.

SLA — Service Level Agreement (The Contract)

An SLA is a contractual agreement with external customers or business partners. It defines what your service promises and what happens if you break that promise (usually financial penalties or credits).

SLAs are owned by business/legal teams. They are external-facing and enforceable.

Example SLA:

  • "We guarantee 99.9% monthly uptime. If we fall below this, customers receive a 10% service credit."

SLAs answer: "What did we promise, and what do we owe if we break it?"

Important: SLAs are typically more lenient than SLOs. You set your internal target (SLO) higher than your external promise (SLA) so you have a buffer before breaching customer commitments.

How They Relate 

SLI (measurement) → SLO (internal target) → SLA (external commitment)

Availability = 99.72%       ← SLI (what happened)
Target: 99.9% uptime        ← SLO (what we aimed for)
Guarantee: 99.5% uptime     ← SLA (what we promised customers)
Enter fullscreen mode Exit fullscreen mode

Notice the gap: the SLO (99.9%) is stricter than the SLA (99.5%). That buffer gives engineering time to react before hitting contractual obligations.

Practical Example

Scenario: You run a SaaS app for small businesses.

  • SLI: HTTP availability measured by your uptime monitor
  • SLO: 99.9% availability in any rolling 30-day window (internal goal, tracked by engineering)
  • SLA: 99.5% availability guaranteed to paying customers (external commitment in your Terms of Service)

Your uptime monitor (like Vigilmon) tracks the SLI. You use it to know if you're on track for your SLO. If you approach or breach the SLO, you have advance warning before you breach the SLA.

Common Mistakes

Setting SLOs equal to SLAs. This leaves you no room to detect problems before customers notice. Always have a buffer.

Measuring the wrong SLI. Measuring "is the server responding" is not the same as "is the user experience working." A server can return 200 OK with a broken page.

Not publishing SLOs internally. An SLO nobody enforces is theater. Teams need to see the metric and respond when the error budget runs low.

Ignoring false positives in monitoring. A single-region uptime monitor might fire false alerts, which can distort your SLI measurements. Multi-region consensus monitoring (like Vigilmon uses) gives you cleaner signal.

Quick Reference

Term What it is Who owns it Answers
SLI The raw metric Engineering What happened?
SLO The internal target Engineering What are we aiming for?
SLA The customer promise Legal/Business What did we commit to?

Getting Started

  1. Pick 2-3 SLIs that actually represent user experience (availability + latency are usually the right start)
  2. Set SLOs based on what your users actually need (not just what feels achievable)
  3. Set up monitoring so you can measure your SLIs continuously
  4. Only add an SLA once you've validated that you can consistently hit your SLO

Vigilmon monitors your uptime from multiple regions and gives you continuous availability data — the foundation of any SLI measurement.

Top comments (0)