Back to BlogSLO vs SLA for SREs: Why 99.95% Must Beat 99.9%

SLO vs SLA for SREs: Why 99.95% Must Beat 99.9%

NTNetverge TeamNetverge editorial teamPublished
slo vs slaslo and sla differencesla vs sloService Level Objectives explainedslo vs sla examples

An SLI measures service behavior, an SLO is the internal reliability target built from those measurements, and an SLA is the external contract that can carry penalties. Error budgets connect the SLO to real team decisions, a model laid out in Google SRE guidance and in USENIX SREcon material. We built Netverge to unify network monitoring, documentation, ticketing, and automation.

TL;DR:

  • Start with one critical user journey, measure its baseline, and set a realistic target; a 100% SLO is usually inappropriate.
  • A 99.95% SLO over 30 days paired with a 99.9% SLA leaves a margin; limit contract reporting to covered customers and keep internal measurements broader.
  • Use p95 latency instead of averages, define good and valid events consistently, and keep alert thresholds separate from user experience indicators.
  • Calculate the error budget as 100% minus the SLO target, and choose a longer window, such as a quarter, for especially strict targets.
  • When the error budget runs out, pause feature releases and prioritize reliability; escalate before contract periods close if budget burn threatens credits.

Table of Contents

What do SLI, SLO, and SLA actually mean?

Teams mix these terms up because they describe one chain at different points. Here is the shared vocabulary we use in docs and runbooks:

  • SLI (service level indicator): a direct measurement of service behavior. Examples: availability as the percentage of successful requests, latency at the 95th percentile, or an error rate.
  • SLO (service level objective): an internal target tied to one or more SLIs, such as 99.9% availability measured over a rolling 30-day window. The window matters as much as the number, because it defines when the target is judged.
  • SLA (service level agreement): the customer-facing agreement. It is often looser than the SLO and can include credits or penalties when missed.

Ownership differs too. Engineering owns SLIs and SLOs. Legal, finance, and sales share ownership of the SLA, because a missed SLA costs money, not just attention. The Google SRE book suggests a simple test: ask what happens if the target is not met. If nothing contractual happens, it is an SLO. If there is a consequence, it is an SLA.

How do SLIs feed SLOs, and SLOs feed SLAs?

The chain runs from measurement to internal target to external promise. The Google Cloud SRE fundamentals post describes the SLO as a precise target and the SLA as often a looser external promise. Three patterns show how that plays out:

  1. Availability: you measure an availability SLI over 30 days and set a 99.95% SLO. The SLA might promise customers 99.9%, with defined credits if you miss it. The gap between 99.95% and 99.9% is your safety margin before money changes hands.
  2. Latency: you measure p95 latency and write the SLO as "95th percentile at or below X milliseconds, for the chosen share of requests." Requests that exceed X count against the error budget, so a slow release burns budget even when nothing is technically down.
  3. Traffic scoping: if the SLA covers only paying customers, count only their requests for SLA reporting. Measurement must separate paying-customer queries when the SLA counts only them. Teams also sometimes exclude out-of-quota responses from SLA accounting, so a customer exceeding their limit does not trigger a credit. Keep internal SLO measurement broader, so you still see the whole picture.

How do you set SLOs and calculate error budgets?

Start from what users do, not from what your dashboards happen to collect.

  1. Map critical user journeys (CUJs). Assign one or more SLIs per capability. SREcon18 guidance recommends multiple SLIs, such as latency, correctness, and freshness, which can combine into compound SLOs.
  2. Measure first. Capture baseline SLI data before locking a target. The same talk's advice is blunt: when in doubt, measure first.
  3. Pick a realistic target. Reflect user impact and what your organization can sustain. A 100% target is usually inappropriate, per the USENIX service levels talk.
  4. Compute the error budget. The budget is 100% minus the SLO percentage, as the SRE book defines it, often over a monthly window.

Here is how the error budget translates into allowed downtime over a month:

SLO target Error budget Allowed downtime
A chosen target 100% minus the target Depends on the target and time window

Pro Tip: Higher SLOs leave tiny budgets, so the same SRE book guidance suggests longer budget windows, such as quarterly, for stricter targets.

Then write the policy before you need it. When the budget is spent, freeze feature releases, prioritize reliability fixes, and start an investigation. Decision-making using SLOs frames this as the point of the whole exercise: error budgets tell you when to shift focus from feature work to reliability work.

How do you measure SLIs without fooling yourself?

Good SLOs depend on honest measurement. These are the SLI types and signals we see most often:

  • Availability: successful requests over total requests, taken from client-side probes, server-side counters, or logs. Client-side data shows what users feel.
  • Latency: use percentiles such as p95, not averages. An average hides the slow tail that users complain about.
  • Correctness and freshness: did the system return the right data, and how stale was it?
  • Event counting: define once what counts as a good event and a valid event, then never change it silently.

Watch for these pitfalls:

  • Inconsistent counting between dashboards and reports.
  • Silent exclusions that quietly inflate compliance.
  • Conflating alert thresholds with SLI definitions. Alerts fire on symptoms. SLIs describe user experience.
  • Mixing all traffic together when the SLA covers only specific customers.

Keep alerting and SLO measurement separate, and choose time windows and rollups deliberately. Our guide to real-time monitoring methods covers collection techniques that reduce measurement error. For managers aligning service metrics with business goals, this guide to measuring service quality is a useful companion.

How do SLOs shape SLAs and daily operations?

An SLA should include only metrics that are customer-impacting, measurable, and stable. Businesses usually pick looser SLA numbers than SLO numbers, so ordinary bad weeks do not turn into credits. The Google SRE book notes that business and legal teams define SLA penalties, while SRE helps estimate how likely the SLO is to be met.

  • Track compliance per contract period. Keep the logs and metrics needed to calculate a credit or answer a dispute, scoped to the customer in question.
  • Use error budgets for rollout decisions. A healthy budget supports faster releases. A depleted one shifts on-call focus to stability.
  • Escalate early. When budget burn threatens an SLA, bring product and legal in before the period closes, not after.

Our write-up on SLA monitoring metrics for MSPs shows how to avoid false breaches in this process.

What I have learned about running SLOs in practice

What I have learned about running SLOs in practice — overview diagram

Most early mistakes come from ambition. Teams define too many SLOs, wire up none reliably, and abandon the effort soon after. Start with one critical user journey and one plain availability SLO, and let the first error budget teach you what to refine.

Measurement friction is the real tax. When metrics, topology, and tickets live in separate tools, nobody trusts the numbers. That is why we built Netverge to unify monitoring, documentation, and ticketing, with AI agents that triage incidents.

— Jim

FAQ

Is SLO the same as SLA?

No. An SLO is an internal reliability target, while an SLA is a customer-facing agreement that can include credits or penalties. SLOs are usually stricter, which leaves a margin before an SLA is breached.

What is SLA, SLI, and SLO?

An SLI is a direct measurement of service behavior, such as availability or latency. An SLO is a target set on that measurement, and an SLA is the external promise built from it. Together they run from measurement to target to contract.

How do you calculate SLI and SLO?

Divide good events by valid events over a defined window to get the SLI, such as successful requests over total requests across 30 days. Set the SLO as the target for that ratio, and subtract it from 100% to get your error budget. Measure baseline data before choosing a number.

What does SLO mean in software?

In software, an SLO is the level of reliability a service aims to deliver, expressed as a target on an SLI over a time window. Teams use it to decide when to ship features and when to fix reliability.

Sources

Recommended