[DevOps Architecture] SLO and SLI

About this article

As the eleventh installment of the “DevOps Architecture” category in the series “Architecture Crash Course for the Generative-AI Era,” this article explains SLO, SLI, and SLA.

100% uptime is not a goal to pursue - the essence of SLO is buying dev speed with error budgets. This article covers the relationship of SLI (actuals) / SLO (targets) / SLA (contracts), error-budget operations, choosing user-perspective SLIs, and per-service-type x target numerical gates.

What are SLO and SLI in the first place

Think of on-time train performance. Japanese railways hold a numerical target like “on-time rate of 99.x%”, drawing a clear line on how many minutes of delay are acceptable and what triggers improvement. Aiming for 100% leads to over-investment, so setting a realistic target and operating against it is the railroad’s wisdom.

SLO is the web-service version of an on-time target. It numerically defines service quality goals like “99.9% uptime” or “response time under 200ms.” SLI is the actual measurement, and SLA is the contractual value with customers.

Without SLO, “make it more stable” and “make it faster” never end, leading either to over-investment in quality or neglecting quality until a major incident.

Why SLO and SLI are needed

First, because they define “good enough”. Without a number, reliability is argued about in feelings and never settles. Second, because they give business and engineering a common language. An availability target is a sentence both sides can read. Third, because they make improvement priorities obvious. Which of latency, error rate and availability is furthest from target tells you where to spend next.

The difference between SLI, SLO and SLA

The iron rule is SLO < SLA. Without making the internal target stricter than the contract value, you break the promise made with customers. SLO is an internal guardrail with margin from SLA.

The typical SLIs are as follows.

SLIs are metrics measuring user experience, with the following standard patterns. “CPU usage” and “memory consumption” aren’t SLIs (indirect metrics of user impact).

The right answer is choosing axes where users feel broken / slow / wrong.

A guideline table for availability

“99.9%” is hard to feel, but converting to downtime makes judgment easier. Choose appropriate level per business requirement.

“99.999%” is the extremely strict level allowing only 20 sec monthly downtime. Excessive for most services.

The error budget and SLO-based operation

The “allowable failure amount” for SLO. The thinking is “aim for 99.9%” = “0.1% can fail,” with this 0.1% being the error budget. Used as the operational rule of “release aggressively within budget, freeze releases on over-budget.”

SLO: 99.9% availability (allow 43 min monthly downtime)
|- Beginning of month: 43 min budget
   |- 10 min down on release → 33 min remaining
   |- 30 min down on incident → 3 min remaining
   |- Budget exhausted → freeze releases, prioritize stabilization

While error budget remains, accelerate development; on exhaustion, invest in reliability improvement - the mechanism balancing dev and ops.

Choosing the SLO runs as a process.

SLOs aren’t decided arbitrarily but agreed with business. Tech-leaning SLOs ignoring user impact are meaningless, requiring agreement among business, sales, and tech.

The safe approach is setting loose first, then gradually tightening. Promising 99.99% from the start can’t be kept.

SLO-based operation is what the budget is for.

Once SLO is set, operational decisions get numerical. “Should we release?” or “Should we alert?” gets decided by numbers, not feel. This is the essence of SRE operations.

When error budget reaches “0,” stopping new features and improving reliability is the SRE rule. Failing to follow loses both reliability and speed.

The moment availability SLO is articulated, the dev team’s atmosphere changes - a standard anecdote of SRE introduction. At sites that agreed on 99.9% numerically, where the vague tension of “always cautious on releases” had pervaded, conversations like “32 min left this month, OK to fail” became possible, doubling new-feature deploy speed - cases also told. SLO is shown as not a number that constrains, but a number that lets you step in with confidence.

SLO alerts and burn rate

Alerts that early-detect SLO violations use burn rate (budget-consumption speed). Consume 10% of monthly budget in 1 hour - warning; 50% - critical - judging by the slope of budget consumption.

SLO burn rate is more meaningful than threshold-based alerts (CPU exceeding 80% etc.). Burn rate reflects user impact.

Multi-window, multi-burn-rate alerting is the refined form.

The technique of monitoring both rapid consumption in short time windows and persistent consumption in long windows. Detects both “rapidly eating budget in 1 hour” and “gradually eating over 24 hours.”

Detailed in Google SRE Workbook - the standard alert design of modern SRE.

Three scenarios

If you are building solo or on internal tools

Watching availability at 99 percent and latency is enough. You do not need error-budget operation; just get the metrics platform in place. Allowing seven hours of downtime a month is a realistic level and avoids over-investment. Setting an SLO you cannot measure is meaningless, so the monitoring platform comes first.

Personal / Startup: Ship in One Month Is Correcten.senkohome.com/arch-intro-case-startup/

If you are a small or mid-size SaaS

This is the stage for three pillars: 99.9 percent availability, P95 latency and error rate. Start with the SLO features in Datadog or Grafana Cloud and adjust the targets quarterly against what you actually measure. This is also where the rule of freezing releases when the error budget runs out should go into operation. As B2B contracts increase, raising the target to 99.95 percent comes into view.

Small-Mid SaaS - Lean on Managed and Run with Few Peopleen.senkohome.com/arch-intro-case-saas/

If you are a large enterprise or in finance

The world of 99.99 percent availability and multi-window burn-rate alerts. Because an SLA breach turns directly into a penalty, designing the SLO stricter than the SLA, with margin, is essential — as is a route that takes an incident notification to the executive level immediately.

Large-Enterprise Core: Design That Holds Up for Yearsen.senkohome.com/arch-intro-case-enterprise/

SLO-level x service-type numerical gates

Note: Industry baseline values as of April 2026. Will become outdated as technology and the talent market shift, so requires periodic updates.

SLO at just “99.9%” is vague - the practice is numerically setting multiple axes per service type.

Burn-rate alert numerical gates: Critical on consuming 2% of budget in 1 hour (burn rate > 14.4x), High on 5% in 6 hours (6x), Warning on 10% in 3 days (1x). This is the Google SRE Workbook standard firing criteria.

For SLO, separate numbers per service type. Same standard for all services becomes excessive or insufficient.

AI decision axes — AI features need a four-axis SLO

4 new SLO axes for AI features

When incorporating AI into a product, traditional SLOs (availability, latency) alone can’t measure quality. The following 4 axes need to be additionally defined as AI-feature-specific indicators:

• Accuracy — the rate of correct AI answers (the inverse of hallucination rate)
• Latency — time to response (for LLMs, measure TTFB to streaming start)
• Cost — LLM API cost per request (design to degrade when ceiling is exceeded)
• Safety — occurrence rate of harmful or inappropriate output

By quantifying these as SLOs and incorporating them into error-budget management, quality degradation in AI features can be objectively detected.

AI auto-monitors error budgets for release decisions

Operations are spreading where error-budget remaining is calculated in real time and rules like “auto-block new feature releases at 30% remaining” or “accelerate releases at 60%+ remaining” are embedded in CI pipelines. The decision logic itself is simple threshold comparison, but AI is becoming able to analyze error-budget consumption trends and predict “at this pace, budget will be exhausted by next week.”

Pitfalls and forbidden moves

Here are the six most dangerous ways SLO operation goes wrong. Every one produces a state where the numbers are not doing any work.

Conversely, holding releases back while error budget remains is a loss of development speed through over-stabilisation. The budget exists to be spent.

Author’s note - cases of “dev stopping from pursuing 100%”

Cases of pursuing perfection only to have key release speed stop are perennial SRE talking points.

There’s a story often heard about a mid-size SaaS where, without setting SLO, “zero incidents” was set as goal, and as a result, no new features shipped for 3 months and customers were taken by competitors. The typical case where dev resources got sucked into infinite tasks like “investigate every Warning” or “resolve every latency degradation,” stopping business. After introducing SLO (99.9%) and changing to operations of allowing in-budget incidents, release speed returned to over double - many such patterns reported.

Another, as a reverse pattern, a financial-system company had SLA (customer contract) at 99.9% but internal SLO also at 99.9%, and an incident exceeding SLA → large penalties for contract violation. A typical case told of the lesson that SLO must be set stricter than SLA with margin design.

Both have “no numerical agreement” as the root cause, slapping home that SLO isn’t a constraining number but a dial for engineering-handling speed-reliability balance.

What to decide - what is your project’s answer?

For each of the following, try to articulate your project’s answer in 1-2 sentences. Starting work with these vague always invites later questions like “why did we decide this again?”

• Critical path (SLO-target features)
• SLI (what to measure)
• SLO target (99.9%, 99.95%, etc.)
• Difference from SLA (SLO < SLA)
• Error-budget operational rules (per-remaining decision criteria)
• Burn-rate alerts (short / mid / long term)
• Review frequency (quarterly / semi-annually)

Related Articles

Summary

This article covered SLO and SLI, including SLI/SLO/SLA differences, typical SLIs, availability guidelines, error budgets, burn-rate alerts, per-service-type numerical gates, and AI-era 4-axis SLO.

Choose SLI by user impact, SLO<SLA with margin design, release decisions by error budget, AI era guarantees quality with 4-axis SLO. That is the practical answer for SLO/SLI design in 2026.

Next time we’ll cover incident response (on-call, postmortem).

Back to series TOC -> ‘Architecture Crash Course for the Generative-AI Era’: How to Read This Book

I hope you’ll read the next article as well.