SLO vs SLI vs SLA: What Developers Actually Need to Know

SLO, SLI, SLA — you've seen these acronyms in job descriptions and engineering blogs. This guide cuts through the jargon and shows you what these terms mean in practice, plus how to implement them without a dedicated SRE team.

The Definitions (Simply)

SLI — Service Level Indicator

An SLI is a measurement of how your service is performing.

Examples:

• uptime_percentage = (minutes up / total minutes) × 100
• p99_latency_ms = the 99th percentile response time
• error_rate = (failed requests / total requests) × 100
• successful_logins_per_minute = business-level metric

SLO — Service Level Objective

An SLO is a target for an SLI. It's an internal goal your engineering team commits to.

Examples:

• uptime_percentage >= 99.9% (three nines)
• p99_latency_ms <= 500ms
• error_rate <= 0.1%

SLA — Service Level Agreement

An SLA is a contract with consequences — usually with customers or between companies.

Example:

• "We guarantee 99.9% uptime. If we miss it, we credit you 10% of your monthly bill."

The Relationship

SLI  = what you measure
SLO  = what you target internally  (set lower than SLA)
SLA  = what you promise externally (with financial penalty)

SLO is always stricter than SLA:
  SLA: 99.5% uptime
  SLO: 99.9% uptime  ← internal target gives buffer before SLA breach

Error Budget

The error budget is the difference between 100% and your SLO:

SLO = 99.9% uptime
Error budget = 0.1% downtime per month
             = 0.001 × 30 × 24 × 60
             = ~43 minutes per month

When you burn through your error budget, you stop shipping features and focus on reliability.

Practical SLOs for Small Teams

You don't need a big SRE team to run SLOs. Start simple:

Uptime SLO:

• Target: >= 99.9% (43 min downtime/month allowed)
• SLI: measured by Vigilmon external uptime checks
• Alert: page on-call when downtime starts

Latency SLO:

• Target: p95 < 300ms
• SLI: measured by your APM tool or server logs
• Alert: page when p95 exceeds threshold for 5 minutes

Setting Up Uptime Monitoring for Your SLO

Vigilmon is the simplest way to measure your uptime SLI:

1. Add monitor at https://your-app.com/health
2. Set 1-minute check interval
3. Enable alerts (email + Slack)
4. Check your monthly uptime report

Vigilmon's dashboard shows uptime percentage over time, giving you your SLI data for reporting.

Common SLO Mistakes

1. Setting SLO = SLA — leaves no buffer. Always keep internal SLO stricter.
2. Too many SLOs — start with 1-2 SLOs per service. Three is usually enough.
3. Measuring wrong thing — uptime of your servers isn't the same as uptime from user's perspective. Measure externally.
4. No error budget policy — SLOs without a stated response to burning the budget are just numbers.

Minimal SRE for Small Teams

# Your minimum viable SRE setup:
monitoring:
  external_uptime: Vigilmon          # measures SLI
  internal_metrics: Prometheus       # latency, error rate
  logs: Loki or CloudWatch           # debugging

alerts:
  on_call: rotate weekly             # who gets paged
  escalation: team lead after 15min  # if no ack

SLO_review: monthly                  # did we hit targets?

Summary

• SLI: the metric (uptime %, latency, error rate)
• SLO: your internal target ("we aim for 99.9%")
• SLA: your customer-facing promise with consequences
• Error budget: the allowed downtime/degradation within your SLO

Start measuring your uptime SLI today at vigilmon.online — free for 5 monitors.