SLOs for AI features: how to set targets a model can hit

Answer first: an AI feature needs the same two things a payments API needs, a service level objective and an error budget. The definitions change because the output is probabilistic. Latency you measure the usual way. Quality you measure as a pass rate over a fixed evaluation set, and the error budget is how much regression you tolerate before you stop shipping model and prompt changes.

Most teams ship an LLM feature with an uptime dashboard and nothing else, then get surprised when users complain about answers that were technically 200 OK and completely wrong. Here is how to set targets that catch that, using numbers you can actually hold a model to.

Why a deterministic SLO does not fit an AI feature

A classic REST endpoint is either correct or it errors with a 5xx. Site reliability practice built decades of tooling on that: availability, success rate, latency percentiles. An LLM feature breaks the assumption. It can return a 200 response, on time, that is a confident wrong answer. Uptime says everything is fine while the feature quietly loses trust.

So the failure that hurts most, a plausible but incorrect output, is invisible to a standard SLO. You need a quality dimension measured directly on the content, not just on the transport.

The three dimensions to set targets on

• Latency: p50 and p95 for time to first token and for the full answer.
• Availability: the feature returns something usable, including a graceful fallback, rather than an error page.
• Quality: a pass rate over a golden set graded by an evaluation, not a vibe check.

Setting the numbers

Targets only mean something if they are specific. Here are defensible starting points for an interactive assistant feature; adjust to your product, then hold the line.

Latency SLO

For anything a user waits on, aim for p95 time to first token under about 1 second and p95 full-answer under 2.5 to 4 seconds. Stream tokens so perceived latency tracks time to first token instead of total generation time. Set the alert on p95, not the average, because the average hides the slow tail that users actually feel.

Quality SLO

Build a golden set of 150 to 300 real cases with known-good answers, drawn from actual usage rather than invented prompts. Grade each release with an LLM-as-judge or with exact and semantic matching, and set the SLO as a pass rate, for example 92 percent on the golden set, measured on every model or prompt change. This is where an eval harness earns its keep; we cover building one in building an eval set from production failures and using it as a gate in an LLM-as-judge release gate.

Availability SLO

Count the fallback path as available. If the primary model times out or returns a 429, a cached response or a smaller backup model still counts as serving the user; a spinner that never resolves does not. A target of 99.5 percent usable responses over 30 days is a reasonable start, and it forces you to build the fallback instead of hoping the primary never fails.

The error budget makes it operational

An SLO without a budget is a wish. Define the error budget as the allowed shortfall over a window. If the quality SLO is 92 percent over 30 days, the error budget is the 8 percent of graded cases you are permitted to fail in that window. The budget is what turns a number on a dashboard into a decision rule.

The policy is simple. While you are inside budget, ship model swaps and prompt edits freely, because you have room to absorb a small regression. When you burn through the budget, freeze changes and spend engineering time on reliability, evals, and retrieval quality until you recover. This is the same burn-rate logic SRE uses for latency, applied to answer quality.

How to measure the burn

Log every production call with its inputs, outputs, latency, and model version. Sample a slice daily and grade it against the golden set and against fresh production failures. Feed newly discovered failures back into the golden set so the bar tightens over time instead of drifting. Watching quality and latency together is the point of good observability; the tradeoffs between metrics and evals are worth reading in observability versus evals for AI agents.

Wiring it into release

Gate deploys on the quality SLO the same way you gate merges on tests. A model swap or prompt edit that drops golden-set pass rate below target does not ship, full stop. Turning fuzzy expectations into a checkable pass rate is exactly the discipline described in writing acceptance criteria as evals, and it is a core part of the AI features we ship for production SaaS teams.

None of this requires exotic tooling. A golden set in version control, a nightly grading job, latency percentiles from your existing traces, and a written burn-rate policy cover most of it. The hard part is the decision to hold the line when the budget is spent, which is a management choice more than a technical one.

Frequently asked questions

What is a good quality SLO for an AI feature?

A pass rate on a fixed golden set of real cases, graded by an evaluation. Something like 92 percent on 150 to 300 cases is a reasonable start; the exact number matters less than measuring it on every model and prompt change.

How is an error budget different from an SLO?

The SLO is the target, for example 92 percent quality over 30 days. The error budget is the allowed shortfall, the 8 percent you are permitted to fail. You ship freely while inside budget and freeze changes once it is spent.

Do latency SLOs work differently for LLM features?

The measurement is the same, but time to first token matters more than total time when you stream, because perceived speed tracks the first token. Alert on p95, not the average, so the slow tail does not hide.

How do I measure quality in production?

Log every call, sample a daily slice, and grade it against your golden set and against new production failures. Add the new failures back into the golden set so the bar tightens over time.