MLOps
Service-Level Objectives and Error Budgets for ML
Define ML-aware service indicators, objectives, error budgets, and policies that balance reliability, quality, freshness, and change.
By the end you can
- Write service-level indicators around user-visible ML events
- Set objectives for availability, latency, freshness, completeness, and decision validity
- Use error budgets and burn rates to govern release and operational work
- Avoid SLOs that reward uptime while hiding degraded predictions or workflows
A service can be available while every decision is unusable
The Epic Sepsis Model was reachable, it was fast, and it answered. Michigan Medicine then checked what it had answered. The validation covered 27,697 patients and 38,455 hospitalizations between 6 December 2018 and 20 October 2019. Hospitalization-level AUC: 0.63 (95% CI, 0.62-0.64). The hospital's operations committee had put the alerting threshold at 6, a value inside the vendor's recommended 5-8 range. At that threshold, Wong and colleagues reported in JAMA Internal Medicine in 2021: “The ESM also did not identify 1709 patients with sepsis (67%) despite generating alerts for an ESM score of 6 or higher for 6971 of all 38 455 hospitalized patients (18%).”
A separate validation in 2024 took the same vendor model, Epic Sepsis Predictive Model v1.0, across 145,885 emergency-department encounters at two county hospitals in Harris County, Texas. Sensitivity was 14.7%. Positive predictive value was 7.6%, inside a six-hour window.
Nothing in that record is an availability failure. Every alert arrived. Two thirds of the sepsis patients did not get one, and 18% of all admissions got one they had to absorb. Availability is important. But an ML service needs indicators that stand for good user events, and freshness, valid decision envelopes, fallback rate and downstream acceptance may matter alongside transport success.
Comparison
SLO, release gate, and business target are related but distinct
Each controls a different decision horizon, and the middle one has a dated, public instrument behind it. In October 2023 the FDA, Health Canada and the UK MHRA jointly published five guiding principles for Predetermined Change Control Plans covering machine learning-enabled medical devices. A PCCP is a plan the manufacturer proposes. It specifies certain planned modifications to a device, the protocol for implementing and controlling those modifications, and the assessment of impacts from modifications. The first principle, Focused and Bounded, also asks for mechanisms to detect and revert or stop implementation of a change that fails to meet specified performance criteria. The third, Evidence-Based, asks that “methods and metrics used to measure device performance are scientifically and clinically justified, in proportion to the risk and consistent with other evidence gathered throughout the TPLC”. The same three regulators had jointly issued 10 Good Machine Learning Practice principles in 2021.
That is what a release gate looks like when it is written properly: bounded to named modifications, agreed before the change, with the revert path specified in advance. An SLO does none of that. It governs repeated behavior over a window and produces a budget. A business target does neither. It moves for reasons no gate and no budget control.
SLO
A reliability objective for repeated service behavior over a window.
- Supports operational tradeoffs
- Uses good-event indicators
- Creates an error budget
- Example: valid scores before deadline
Release gate
Evidence a candidate must pass before or during exposure.
- Applies to a specific change
- Can include offline and canary tests
- May be stricter than steady-state SLO
- Example: no protected-slice regression beyond tolerance
Business target
An outcome the product seeks to influence.
- May depend on many factors
- Needs causal interpretation
- Can move slowly
- Example: reduce avoidable equipment downtime
Visual
An ML service has several reliability dimensions
One availability number cannot represent all of them. The sepsis validation shows why, because it scores differently on each. Transport reliability: the model returned. Timeliness: it returned inside the clinician's window. Data validity and decision validity: unexamined by any uptime metric. Workflow usability: alerts on 6,971 of 38,455 hospitalizations, 18%, while 1,709 of the 2,552 sepsis patients — 67% — received none.
An 18% alert rate is a capacity fact before it is an accuracy one. It describes what the nursing staff has to absorb per shift, and no transport indicator contains it. The two county hospitals in the 2024 validation reach the same place from the other side. A positive predictive value of 7.6% means roughly twelve alerts to find one true case, on a service that was up the whole time.
Transport reliability
Requests or jobs complete without infrastructure failure.
Timeliness
Results arrive before the user or downstream deadline.
Data validity
Features meet freshness, coverage, schema, and semantic requirements.
Decision validity
The service uses an approved model, policy, fallback, and eligible input.
Workflow usability
The output can be acted on within capacity and control constraints.
An SLI needs a denominator and a definition of good
A useful service-level indicator counts good events over eligible events. The unit might be requests, scored entities, completed batches, or review decisions. Eligibility rules and exclusions should be explicit, so the metric cannot improve by dropping difficult traffic.
Objectives should reflect product expectations and cost, not round numbers copied from infrastructure. MLPerf Inference publishes exactly this kind of number and shows its reasoning. The Llama 2 70B benchmark introduced in v4.0 (March 2024) used server latencies of 2s time-to-first-token and 200 ms time-per-output-token. The Interactive variant added in v5.0 (April 2025) tightened them to a 99th-percentile TTFT limit of 450 ms and a 99th-percentile TPOT of 40 ms. MLCommons gave the reason when it announced v5.0: “To prioritize reliability under peak demand, MLPerf adopts a stricter 99th percentile threshold of 25 tokens/second (TPOT of 40ms), ensuring consistent responsiveness even during high-load scenarios.”
Three things there are worth copying. The percentile is stated rather than implied, so nobody argues later about whether the average passed. The objective is a pair — time to first token and time per output token — because one number could not describe the user event. And it changed between v4.0 and v5.0. An objective tracks what users will tolerate, and 200 ms became 40 ms when the tolerance moved.
Case
Five nines leaves 0.001% of a quarter to spend
Set a target and you have also set what you may spend. Google's SRE book works the error budget from the SLO, in its chapter on embracing risk: “imagine that a service’s SLO is to successfully serve 99.999% of all queries per quarter. This means that the service’s error budget is a failure rate of 0.001% for a given quarter. If a problem causes us to fail 0.0002% of the expected queries for the quarter, the problem spends 20% of the service’s quarterly error budget.” Fail 0.0002% of the quarter's queries, and a fifth of the quarter's budget is gone.
The same chapter's key insight refuses the round number at the top of the scale: “100% is probably never the right reliability target: not only is it impossible to achieve, it’s typically more reliability than a service’s users want or notice.” Red Hat's SRE reference, an independent host, defines the same object in the same terms: “This downtime level is referred to as an error budget—the maximum allowable threshold for errors and outages. With SRE, 100% reliability is not expected—failure is planned for and expected.”
Example
An exclusion makes the SLO look healthier
On 4 October 2020 Public Health England disclosed that 15,841 positive COVID-19 cases were missing from the reported daily case figures. They had been recorded between 25 September and 2 October. The data-load files had hit a maximum file-size limit. 11,968 of them — over 75% — fell in the final three days. Fetzer and Graeber treated the gap as a natural experiment, and their abstract in PNAS opens with the mechanism: “Because of a coding error involving spreadsheet data used by the health authorities, a total of 15,841 COVID-19 cases (around 20% of all cases) failed to have timely contact tracing.” This is the silent-exclusion failure with its figures attached.
- Metric definition: the published daily series counted the cases the load files carried, not the positive tests that had been taken.
- Silent exclusion: rows past the maximum file-size limit were dropped before the reported figure was formed — 15,841 cases between 25 September and 2 October.
- Reported result: the series stayed green and continued to publish, with the loss concentrated where it was hardest to notice: 11,968 of the missing cases, over 75%, sat in the last three days.
- User reality: those cases were not traced in time. Fetzer and Graeber estimated that cases which did get properly traced saw 63% fewer subsequent infections and 66% fewer subsequent deaths over the following six weeks.
- Repair: define the eligible population upstream of the pipeline — tests taken, not rows loaded — and publish the exclusion count as a first-class number beside the metric it protects.
Steps
Create an ML-aware SLO
Start from the user event and work backward to measurable evidence: define the event and the population before any internal exclusion, define good, set the objective and window, write the error-budget policy, then validate against real incidents.
Step four is the one teams skip. It is also the step CrowdStrike rewrote after 19 July 2024, when its remediation committed to a canary-first staged rollout for Rapid Response Content that had previously shipped to the whole fleet at once. Step five is what would have caught it earlier. Replay the known harmful periods and ask whether they would have consumed budget and triggered the action the policy names. If a past incident spends no budget, the objective is measuring something other than what happened to users.
1. Define the event and population
Choose requests, entities, batches, or decisions before internal exclusions.
2. Define good
Combine timing, completeness, approved assets, freshness, and valid fallback as needed.
3. Set the objective window
Choose target and period from user tolerance, cost, and failure shape.
4. Write the error-budget policy
Specify burn-rate alerts, release restrictions, and escalation.
5. Validate with incidents
Check whether known harmful periods would have consumed budget and triggered action.
Key idea
An error budget is not permission to harm users
An error budget allows a bounded rate of service-level misses so teams can balance reliability and change. It does not authorize prohibited outcomes, security violations, or breaches of legal and safety requirements.
On 1 August 2012 Knight Capital Americas' systems were available throughout. The SEC's order records what that availability produced: “While processing 212 small retail orders that Knight had received from its customers, SMARS routed millions of orders into the market over a 45-minute period, and obtained over 4 million executions in 154 stocks for more than 397 million shares.” The loss was over $460 million. The order, dated 16 October 2013, found violations of Rule 15c3-5 and imposed a $12 million penalty. No latency objective and no availability objective was breached during those 45 minutes. A budget denominated in service misses had nothing to say about any of it.
Hard constraints remain outside the budget. The error-budget policy should state which failures are budgetable and which trigger immediate containment.
Reliability budgets govern tolerable service misses; they do not override non-negotiable controls.
Analogy
The railway promises completed journeys, not engine uptime
A railway that measures whether passengers reach their destination within an acceptable time has chosen its promise well. Counting engines that start is useful but insufficient if trains skip stations or arrive after connections leave.
The railway has the easier job of the two. An arrival tells it the journey was good. A prediction service cannot read its own quality off the clock. A response delivered inside the deadline may still have been scored on a stale feature under an expired policy. An alert that reaches the ward on time may still be one of the 67% of sepsis cases the model never flagged. Data and policy validity therefore belong inside the definition of a good event.
A service objective should describe the user-visible journey that must remain acceptable.
Use burn rate to connect reliability and change
An error budget becomes operational when fast and slow burn alerts trigger agreed actions. A severe release may consume the budget quickly, and there is a dated measurement of how quickly. CrowdStrike released a Falcon Rapid Response Content update at 04:09 UTC on 19 July 2024 and reverted it at 05:27 UTC. Seventy-eight minutes. The cause was a Content Interpreter that read a 21st input field where only 20 existed. Microsoft estimated 8.5 million Windows devices were affected, under 1% of all Windows machines, which is also a lesson about denominators. Seventy-eight minutes is faster than many incident processes achieve, and it was far too slow. The content had gone to the entire sensor base at once, and the affected machines could not take the revert on their own.
The remediation is an error-budget policy being rewritten in public: “Implement a staggered deployment strategy for Rapid Response Content in which updates are gradually deployed to larger portions of the sensor base, starting with a canary deployment.” Note what changes. Not the target, not the alert threshold. The exposure shape, so that a fast burn is detectable while it is still small.
Chronic low-grade degradation exhausts a budget over a longer window and needs the slow alert instead. Review the policy with product, operations, risk, and engineering. If nobody agrees what happens when the budget is gone, the objective is only a chart.
Case
Two pages, at 2% and 5% of a 30-day budget
The Site Reliability Workbook turns burn rate into alert thresholds. Its chapter on alerting recommends paging when a burn rate of 14.4 holds over one hour, which corresponds to 2% of the SLO budget consumed. A second page fires at a burn rate of 6 held over six hours, worth 5%. A ticket, not a page, is raised at a burn rate of 1 over three days, or 10%.
Each long window is paired with a short one at “1/12 the duration of the long window”: five minutes against the hour, thirty minutes against the six hours, six hours against the three days. The pairing is what stops the alert once the burn stops, so a spike that has already ended does not keep paging. These are recommendations in one table of one chapter, tuned to a 30-day budget. The arithmetic is transferable. The three rows are not a constant of nature.
Figure
Position
A team without an objective has still chosen its acceptable failure rate
Refusing to write the number down does not leave the question open. The answer is settled further down, by whatever the pipeline already does when a file is too large, and by whichever step decides which events are counted at all. Public Health England published a daily case series that was complete as far as its own denominator knew, and nobody lied. The data-load files hit a maximum file-size limit. 15,841 positive cases from 25 September to 2 October never entered the reported figures. 11,968 of them, over 75%, sat in the final three days, where a trend-watcher would notice them last. Somebody fixed the acceptable failure rate at the moment they fixed where the counting starts. That decision was never discussed as one. Fetzer and Graeber later put a number on what it cost: cases that were properly traced saw 63% fewer subsequent infections and 66% fewer subsequent deaths over the following six weeks.
The alternative is not a rounder target. It is an argument held on purpose, in advance, with the arithmetic visible. Google's SRE book does the arithmetic in the open: a quarterly objective of 99.999% leaves an error budget of 0.001% for that quarter, so failing 0.0002% of the expected queries spends a fifth of it. The same chapter states the key insight plainly: “100% is probably never the right reliability target: not only is it impossible to achieve, it’s typically more reliability than a service’s users want or notice.” The Site Reliability Workbook then converts a budget into pages. It recommends a burn rate of 14.4 sustained over an hour, which is 2% of a 30-day budget, and a burn rate of 6 sustained over six hours, which is 5%. Those two numbers are recommendations in one table of one chapter, a starting point rather than a law. Copying them is not what makes a team serious about reliability. Holding the argument they came out of is. An error budget nobody has agreed how to spend leaves the objective as only a chart.
Declining to set an objective is not neutrality. It hands the failure rate to whoever decided where the counting starts.
Key takeaways
- An SLI should count user-visible good events over a clearly defined eligible population, formed before internal exclusions: Public Health England's daily series counted rows loaded rather than tests taken, and lost 15,841 cases.
- ML reliability can include freshness, completeness, approved assets, and valid fallback — a model at 0.63 AUC that alerts on 18% of hospitalizations and misses 67% of sepsis patients breaches none of them while being up.
- SLOs, release gates, and business targets govern different decisions. The Predetermined Change Control Plan principles the FDA, Health Canada and MHRA published in October 2023 show a gate bounded and written before the change, with a revert path.
- Objectives should be stated as percentiles with their reasoning, and revised as tolerance moves: MLPerf Inference went from v4.0's 200 ms time-per-output-token to v5.0 Interactive's 99th-percentile 40 ms.
- Error budgets require a policy linking burn to release and incident actions — the Workbook's 14.4 over an hour (2%) and 6 over six hours (5%), each paired with a window one twelfth as long.
- Prohibited safety, security and legal failures stay outside ordinary budgets: Knight Capital Americas' systems were available for the whole 45 minutes that cost over $460 million and drew a $12 million penalty.