The slo sla difference is one of those things everyone in an engineering organization uses as if they understand it, right up until the moment a customer escalates a reliability complaint and nobody agrees on whether it was an SLO violation, an SLA breach, or neither. The VP of Engineering references the SLA. The SRE references the SLO. The product manager asks what the SLI shows. They are all looking at different parts of the same system and drawing different conclusions.
This guide resolves that confusion permanently. It covers the slo sla difference in precise terms, introduces SLIs as the measurement layer both concepts depend on, explains error budgets as the practical mechanism that makes SLOs operational, shows the PromQL and policy structures that implement all of it in production, and explains why the SLO is always stricter than the SLA and what happens when that relationship is inverted.
The Core Slo Sla Difference in One Sentence
The SLA is the promise you make to customers with legal and financial consequences if you break it. The SLO is the internal target you set for yourself that you must consistently hit to ensure you never break the SLA. The slo sla difference is the difference between a commitment to the outside world and a standard for the inside of your organization.
Everything else in this guide builds on that foundation.
Layer 1 – SLI: What You Actually Measure
Before understanding the slo sla difference, understand the SLI because both SLOs and SLAs are meaningless without one.
An SLI (Service Level Indicator) is a specific, quantitative measurement of service behavior from the user’s perspective. It is the metric, the number that everything else is built on.
Poorly chosen SLIs measure infrastructure, not user experience. CPU utilization is not an SLI. Memory usage is not an SLI. Disk throughput is not an SLI. An engineer caring about CPU is correct, but CPU is a cause, not an experience. Users do not experience CPU. They experience slow responses, failed requests, and incorrect data.
Well-chosen SLIs measure what users experience:
- Availability: proportion of requests that return a successful response.
- Latency: proportion of requests that respond within a threshold (e.g., under 200ms).
- Error rate: proportion of requests that return an error (5xx).
- Throughput: successful requests per second processed.
- Correctness: proportion of responses that return the expected data.
SLI expressed as a ratio (the production pattern):
Availability SLI = good requests / total requests
Where:
good requests = HTTP 2xx and 4xx responses
total requests = all requests (excluding infrastructure errors like 499s)
Example for a 30-day window:
Total requests: 50,000,000
Error responses: 50,000
SLI = (50,000,000 - 50,000) / 50,000,000 = 99.9%The reason 4xx responses count as “good” in availability SLIs: a 404 means the server worked correctly and the request was invalid. The server did its job. A 5xx means the server failed. This distinction matters enormously when calculating SLIs, including 4xx in the error bucket will make your availability appear far worse than users actually experience it.
Layer 2 – SLO: Your Internal Target
An SLO (Service Level Objective) is the target value for an SLI over a specified time window. It is the number your engineering team is accountable for hitting, an internal commitment that determines how much reliability work to prioritize and when to slow down feature releases.
The slo sla difference starts here: the SLO exists entirely within your organization. No customer sees it directly. No contract references it. No penalty triggers when you miss it. What happens when you miss your SLO is that your engineering team knows they are at risk of missing the SLA and takes action before that happens.
SLO definition structure:
SLO: 99.9% availability
SLI: proportion of HTTP requests returning 2xx or 4xx
Window: rolling 30 days
Owner: Platform team
Reviewed: MonthlySLO calculation for availability:
Monthly error budget = (1 - SLO) × total minutes in month
99.9% SLO: (1 - 0.999) × 43,800 = 43.8 minutes/month
99.95% SLO: (1 - 0.9995) × 43,800 = 21.9 minutes/month
99.99% SLO: (1 - 0.9999) × 43,800 = 4.38 minutes/month
99.999% SLO: (1 - 0.99999) × 43,800 = 0.438 minutes/month (~26 seconds)Choosing the right SLO level:
The most common SLO mistake is setting targets based on ambition rather than user need. A payments API genuinely needs 99.99% users abandon checkout on the second failed attempt. An internal analytics dashboard that updates every 15 minutes does not need 99.99% a user who cannot load it at 3am on a Tuesday is not meaningfully harmed. Over-engineering reliability for services where it does not matter depletes engineering capacity for services where it does.
Start with what users actually need, not what sounds impressive. Then set your SLO 10-20% stricter than your SLA to create a safety buffer.
Layer 3 – SLA: The External Commitment
An SLA (Service Level Agreement) is a formal, legally binding contract between a service provider and a customer that defines the expected level of service and the consequences, usually financial penalties or service credits when that level is not met.
The critical slo sla difference from a commercial perspective: the SLA is always weaker than the SLO. If your SLO is 99.9%, your SLA should promise 99.5% or perhaps 99.7%. The gap between them is your buffer, the space that absorbs normal operational variance and prevents SLO misses from automatically triggering SLA breaches and customer penalties.
SLA components that SLOs lack:
- Penalty clauses: what the provider compensates when the SLA is breached (typically service credits of 5-25% of monthly spend).
- Measurement methodology: how availability is calculated, what counts as downtime, what exclusions apply.
- Reporting obligations: when and how the provider reports on SLA performance.
- Escalation procedures: what happens when a breach is detected.
- Exclusions: scheduled maintenance, force majeure, customer-caused outages.
SLA structure example:
Service: Payment API
Commitment: 99.5% monthly availability
Measurement: Calendar month, excluding scheduled maintenance windows
notified 48 hours in advance
Penalty: 5% service credit for each 0.1% below 99.5%
Maximum credit: 30% of monthly invoice
Exclusions: Downtime caused by customer configuration errors,
DDoS attacks exceeding 10x normal traffic baseline,
Third-party payment processor outagesNotice that the SLA commitment (99.5%) is weaker than the internal SLO (99.9%). If your team hits 99.7% in a given month, an SLO miss no customer penalty is triggered. The SLO miss is an internal signal to investigate and improve. The SLA breach at 99.4% is an external event with financial consequences.
The SLO SLA Difference in the Accountability Structure
One of the less-discussed aspects of the slo sla difference is who owns each layer and how accountability flows through an organization.
SLIs are owned by engineering, specifically the team that instruments the service and defines what “good” means for their component.
SLOs are co-owned by engineering and product. The engineering team is accountable for hitting the target. The product team must agree that the target reflects real user needs and that missing it is worth stopping feature work to address. Without product buy-in, SLOs become a dashboard metric that engineers watch but nobody acts on.
SLAs are owned by legal, sales, and customer success with engineering as a constraint. The SLA reflects what the business is willing to commit to commercially. Engineering’s job is to set the SLO high enough that the SLA is consistently reachable.
Teams that skip SLOs and go directly from SLIs to SLAs create an accountability gap. There is no internal target to manage toward, which means the only signal that something is wrong is a customer complaint or a contract breach far too late.
Error Budgets: Where the SLO SLA Difference Becomes Operational
The error budget is the mechanism that converts the slo sla difference from a theoretical distinction into a practical engineering tool. It answers the question: given our SLO, how much failure can we afford this month?
Error budget calculation:
Error budget = 1 - SLO
For a 99.9% availability SLO over 30 days:
Error budget = 0.1% = 43.8 minutes of allowable downtime
OR
Error budget = 0.1% × 50,000,000 requests = 50,000 allowable failed requestsThe error budget is not “planned downtime.” It is the maximum allowable unreliability that keeps the service within SLO. It can be consumed by incidents, by deployments that cause brief availability dips, by maintenance windows, or by any other reliability event.
The key insight: error budgets create a shared language between engineering and product. When a product manager asks “can we deploy this risky change?”, the engineering team’s answer is no longer “it depends”, it is “we have 32 minutes of error budget remaining this month, and this change has historically consumed 5-10 minutes when it goes wrong, so yes, but we need to be prepared to roll back immediately.”
PromQL for error budget tracking:
# Availability SLI - proportion of good requests
job:http_requests:availability = (
sum(rate(http_requests_total{status!~"5.."}[30d]))
/
sum(rate(http_requests_total[30d]))
)
# Error budget remaining as percentage
# SLO = 0.999 (99.9%)
job:http_requests:error_budget_remaining = (
job:http_requests:availability - 0.999
) / (1 - 0.999)Burn rate: the early warning system:
Burn rate tells you how quickly you are consuming the error budget relative to the sustainable pace. A burn rate of 1.0 means you are consuming the budget at exactly the rate that will exhaust it precisely at the end of the window. A burn rate of 10 means you will exhaust it 10x faster than that.
# Burn rate over 1 hour window
# SLO = 0.999 (99.9% availability)
job:http_requests:burn_rate_1h = (
1 - sum(rate(http_requests_total{status!~"5.."}[1h]))
/ sum(rate(http_requests_total[1h]))
) / (1 - 0.999)A burn rate of 14.4 over 1 hour means you will exhaust the entire monthly budget in approximately 2 hours. This is the threshold that should trigger an immediate incident response, regardless of whether an alert has fired on error rate yet.
Burn rate alerting (Google SRE multi-window pattern):
# prometheus/rules/slo-alerts.yml
groups:
- name: slo_burn_rate
rules:
# Fast burn alert - triggers on 1h and 5m windows
# Consumes 5% of monthly budget at this rate
- alert: HighBurnRate
expr: |
job:http_requests:burn_rate_1h > 14.4
AND
job:http_requests:burn_rate_5m > 14.4
for: 2m
labels:
severity: critical
annotations:
summary: "High error budget burn rate on {{ $labels.job }}"
description: "Current burn rate {{ $value | humanize }}x - will exhaust monthly budget in {{ div 720 $value | humanize }} hours"
# Slow burn alert - triggers on 6h and 30m windows
# Catches sustained moderate burns that don't trigger fast alert
- alert: ModerateBurnRate
expr: |
job:http_requests:burn_rate_6h > 6
AND
job:http_requests:burn_rate_30m > 6
for: 15m
labels:
severity: warning
annotations:
summary: "Sustained moderate burn rate on {{ $labels.job }}"The multi-window pattern requiring the burn rate to be elevated in both a short window and a longer window before alerting is what separates burn rate alerting from traditional threshold alerting. It prevents false positives from brief spikes while catching sustained burns that will eventually exhaust the budget.
Error Budget Policy: The Governance Layer
An error budget policy is the pre-negotiated agreement between engineering and product that defines exactly what happens at each budget threshold. Without an explicit policy, error budgets remain dashboard metrics that inform but do not govern decisions.
Error budget policy structure:
# error-budget-policy.yml
service: payment-api
slo: 99.9%
window: 30 days
thresholds:
green:
budget_remaining: ">50%"
actions:
- Ship features at normal velocity
- Run experiments and A/B tests
- Perform standard maintenance
yellow:
budget_remaining: "20-50%"
actions:
- Reduce deployment frequency
- Require SRE sign-off for high-risk changes
- Prioritize reliability work in sprint planning
orange:
budget_remaining: "1-20%"
actions:
- Freeze non-critical feature deployments
- All engineering effort directed at reliability
- Conduct post-incident reviews for recent outages
red:
budget_remaining: "0%"
actions:
- Complete feature freeze
- Engineering reliability sprint
- Escalate to leadership
- No deployments without VP Engineering approvalThe policy must be agreed to by product, engineering, and leadership before the error budget system goes live. A deployment freeze that engineering imposes unilaterally creates organizational conflict. A deployment freeze that was pre-agreed as a consequence of budget exhaustion is just the policy executing as designed.
Latency SLOs: The Dimension Most Teams Miss
Most teams implement availability SLOs. Far fewer implement latency SLOs, even though latency degradation causes user abandonment at rates comparable to availability failures. The slo sla difference applies equally to latency, your SLA might promise p95 latency under 500ms, your SLO targets p95 under 200ms.
Latency SLI definition:
Latency SLI = proportion of requests completing within threshold
(not average latency - average conceals the tail)
Example:
SLO: 99.5% of API requests complete within 200ms (p99.5 < 200ms)
Window: rolling 7 daysPromQL for latency SLO tracking:
# Proportion of requests under 200ms (using histogram)
job:http_request_duration:latency_slo = (
sum(rate(http_request_duration_seconds_bucket{le="0.2"}[7d]))
/
sum(rate(http_request_duration_seconds_count[7d]))
)
# Latency error budget remaining
# SLO: 99.5% of requests under 200ms
job:http_request_duration:error_budget_remaining = (
job:http_request_duration:latency_slo - 0.995
) / (1 - 0.995)Latency SLOs should use the histogram bucket approach rather than percentile functions (histogram_quantile) in recording rules histograms are additive across instances and time, making them compatible with the error budget math. Percentiles are not additive.
The Slo Sla Difference in Practice: A Worked Example
To make the slo sla difference concrete, trace through a realistic incident.
Setup:
- API with a 99.9% availability SLO (internal) and a 99.5% SLA (customer-facing).
- 30-day window, approximately 50 million requests per month.
- Error budget: 43.8 minutes or 50,000 failed requests.
Day 12: A deployment introduces a bug affecting 2% of requests for 3 hours. That consumes approximately 30,000 of the 50,000 allowed failed requests 60% of the error budget in one incident.
Internal SLO status: 99.94% for the month so far still within SLO, but 60% of the budget is gone with 18 days remaining.
Error budget policy triggers: Yellow threshold reduce deployment frequency, require SRE sign-off for risky changes.
Customer SLA status: 99.97% for the month, well above the 99.5% SLA commitment. No customer penalty triggers. No customer notification required.
Day 18: A second incident causes 20 minutes of complete downtime, approximately 20,000 failed requests, consuming the remaining 40% of the error budget.
Internal SLO status: 99.9% exactly on the SLO boundary. Error budget policy goes red. Feature freeze begins.
Customer SLA status: 99.94% still above 99.5% SLA. No breach, no penalty.
This is the slo sla difference working as designed. Two incidents that would have been invisible to customers from an SLA perspective triggered meaningful internal policy responses that protected the organization’s ability to keep the SLA commitment for the rest of the month.
Common Mistakes in the SLO SLA Difference
Mistake 1: SLO equals SLA Setting your SLO at 99.9% and your SLA at 99.9% removes all buffer. The first time your SLO slips to 99.89%, you breach the SLA and trigger customer penalties. Your SLO must be meaningfully stricter than your SLA.
Mistake 2: SLO targets that are never breached If your team consistently achieves 99.98% against a 99.9% SLO, your SLO is probably too low. You are over-investing in reliability for that service. Set SLOs that represent genuine stretch targets, not guaranteed outcomes.
Mistake 3: Error budgets with no policy attached An error budget that exhausts without triggering any consequence teaches teams that the budget is decorative. The policy enforcement is what makes the system work.
Mistake 4: Availability SLO, no latency SLO Services that are “available” but slow are failing users. A complete SLO picture requires both availability and latency targets for any user-facing service.
Mistake 5: Monthly windows without burn rate monitoring A monthly window means you only know you missed your SLO on day 31. Burn rate monitoring gives you that signal on day 3, when you can still do something about it.
Conclusion
The slo sla difference comes down to accountability and scope. SLAs govern what you promise the outside world. SLOs govern how you manage the inside of your organization to keep those promises. SLIs give you the measurement to know whether you are meeting either.
The error budget is the mechanism that makes SLOs operational, converting a reliability percentage into a quantifiable resource that both engineering and product can reason about when making deployment decisions.
At The Good Shell we implement SLO frameworks for startups and SRE teams who need structured reliability practices without building the governance and tooling from scratch. See our SRE and platform engineering services or our case studies to see how this looks in a production context.
For the foundational reference on SLO implementation, the Google SRE Workbook chapter on implementing SLOs is the most rigorous publicly available guide.