--- title: "What an Inference SLO Counts: Requests, Windows and Error Budgets" description: "Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20." canonical: "https://www.leviathansystems.co/articles/inference-slo-request-window-error-budget-units" last-updated: "2026-10-20" --- # What an Inference SLO Counts: Requests, Windows and Error Budgets Leviathan Systems — Technical content Published 2026-10-20; updated 2026-10-20. Two inference reliability promises labeled 99% can describe different objectives. Identify the eligible population, what makes an event good, whether compliance counts requests or qualifying intervals, and the full evaluation period. In the fictional case below, the same observations meet a 99% request objective and miss a 99% qualifying-window objective. The target also determines an allowance in the counted unit; a request allowance cannot establish downtime minutes or a financial remedy. ## Read the reliability statement before comparing its percentage An enterprise comparing two inference offers needs to know what each reliability promise would establish for its workload. A percentage without its counting rule leaves that comparison incomplete. One offer might evaluate individual requests; another might evaluate intervals that pass a separate performance condition. Google's foundational Service Level Objectives chapter distinguishes a service-level indicator, or SLI, from its target, the service-level objective, or SLO. The 2018 SRE Workbook develops good-event ratios and the allowance implied by a target. These references provide a vocabulary for reading an offer, rather than current provider commitments. Start by locating the eligible observations. Does a request mean an end-user call to the inference ingress, an internal model call, or an attempt that can be retried? Which routes, models, regions and outcomes are included? Establish the observation boundary and how work is assigned to the period. Changing those choices can change the result even when the underlying workload is unchanged. Then identify the good-event rule. A terminal response classified as successful, a response completed within a duration limit, and an answer judged correct for its task describe different conditions. The offered rule must say which condition is evaluated. A successful delivery classification alone supplies no assessment of the answer's meaning. References: [SRE-TERMS](https://sre.google/sre-book/service-level-objectives/), [SRE-WB](https://sre.google/workbook/implementing-slos/) ## A windows-based objective has two different thresholds Google Cloud's Concepts in service monitoring documentation, updated October 13, 2026, distinguishes request-based compliance from windows-based compliance. The former counts good requests against eligible requests. The latter counts measurement intervals satisfying a goodness criterion against all intervals in the compliance period, with low- and high-traffic intervals weighted equally. The interval criterion and the overall objective do different work. For the example here, the first asks whether at least 99% of requests inside one interval are good. The second asks whether at least 99% of all the period's intervals qualify. Neither threshold can stand in for the other. The measurement interval is also different from the full compliance period: one interval supplies one classification; the full period supplies the population of classifications being evaluated. This article uses the named Google Cloud reference for those concepts, without applying its configuration limits to every SLO system. References: [CLOUD-SLO](https://docs.cloud.google.com/stackdriver/docs/solutions/slo-monitoring) ## FLEET-SLO-02: fix the population and classifier FLEET-SLO-02 is wholly fictional. Exactly two consecutive, equal ten-minute intervals, W1 and W2, form one completed twenty-minute comparison period. They contain exactly 1,000 eligible calls to one stipulated inference ingress. Every call has one recorded terminal outcome and is counted once, in the interval containing its completion. There are no other eligible calls, pending calls, retries, missing observations or empty intervals. The same stipulated classifier applies throughout: a call is good if its recorded terminal outcome is SUCCESS; every other terminal outcome is bad. The outcome label is an input to this invented example, rather than evidence of response content, latency or a particular failure cause. Complete once-only observation is expressly assumed. W1 contains 900 good requests out of 900 total requests. W2 contains 90 good requests out of 100 total requests. W1 therefore contains no bad requests; W2 contains ten. The durations, classifier and targets illustrate the accounting. They are neither observed provider performance nor recommended service thresholds. The twenty-minute population is deliberately small enough to follow completely; it is not a proposed production compliance period. ## The same case meets the request objective and misses the window objective Across the completed period, good requests total 900 + 90 = 990. Eligible requests total 900 + 100 = 1,000. Request compliance is therefore 990 / 1,000 = 99%. An objective requiring at least 99% good requests is met exactly. Now apply the separate stipulated interval criterion: an interval qualifies only if at least 99% of its requests are good. W1 has 900 / 900 = 100% good requests and qualifies. W2 has 90 / 100 = 90% and does not qualify. Only one of the two intervals qualifies, so qualifying-window compliance is 1 / 2 = 50%. An objective requiring at least 99% qualifying intervals is missed. These conclusions describe different objectives, not contradictory measurements. In request accounting, W1 contributes 900 of the 1,000 observations. In qualifying-window accounting, it contributes one of two votes. The quieter W2 has equal interval weight despite containing one ninth as many requests as W1. There is a second transformation as well as the change of weight: each interval's request fraction becomes a yes-or-no classification. Averaging the two request fractions would give 95%, but that is neither the pooled request fraction nor the fraction of qualifying intervals. The offered objective determines which calculation answers the buyer's question. For this tiny population, meeting a 99% qualifying-window objective would require both intervals to qualify: one of two cannot reach 99%. That arithmetic does not alter W2's separate 99% request-goodness criterion. ## Keep the error-budget calculation in requests For a good-request objective, the allowed bad fraction is one minus the target. Multiplying that fraction by the eligible request count gives the period's bad-request allowance. This is the good-event error-budget reasoning developed in the SRE Workbook. At a 99% request target, the bad fraction is 1%. For FLEET-SLO-02's completed 1,000-request population, the allowance is 1,000 x 0.01 = ten bad requests. The ten observed bad requests consume 10 / 10 = 100% of that allowance. Remaining allowance is ten minus ten = zero requests. The objective is met exactly; zero remaining does not mean the target was missed. Change only the hypothetical request target to 99.5%. The allowed bad fraction becomes 0.5%, giving 1,000 x 0.005 = five bad requests. The unchanged ten bad requests consume 10 / 5 = 200% of that allowance and exceed it by five requests. The 99% observed good-request fraction misses the 99.5% objective. The consumed percentage uses allowed bad requests as its denominator, whereas request compliance uses all eligible requests. Thus 100% budget consumption and 99% request compliance can describe the same completed period. Neither number should be substituted for the other. This comparison keeps both allowances in request units. The one failed interval belongs to the separate windows-based objective; it cannot be inserted into either request-budget calculation. References: [SRE-WB](https://sre.google/workbook/implementing-slos/) ## A completed allowance is different from a moving population The zero remaining above belongs to a completed, fixed population. It is not a countdown to a future incident or permission to cause one. The example assumes the final total of 1,000 rather than estimating future demand. The Google Cloud reference distinguishes calendar-aligned and rolling compliance periods. In a rolling period, older observations leave as newer ones enter. Both the eligible request total and its bad-request count can change, so the corresponding allowance and remaining balance can change too. A buyer comparing reports therefore needs the same period boundaries and evaluation instant as well as the same request definition. Carrying the example's ten-request allowance into another population would preserve a number while discarding its basis. An unfinished calendar period likewise lacks the final request population used in this completed-case arithmetic. References: [CLOUD-SLO](https://docs.cloud.google.com/stackdriver/docs/solutions/slo-monitoring) ## Decide which offered objective the evidence actually supports Suppose two fictional offers cite FLEET-SLO-02's observations. Offer A requires at least 99% good requests across the completed period. Offer B requires at least 99% qualifying ten-minute intervals, with each interval requiring at least 99% good requests. Under the complete stipulated population and classifier, the evidence supports A's compliance claim and establishes that B's objective was missed. It does not establish either offer's future reliability. If A supplies only the number 99% and omits its eligible population or classifier, the same conclusion cannot be recovered from that label. If B omits its interval rule, the buyer cannot decide which intervals qualify. If the period is unspecified, the reader cannot identify the observations to include. Missing definitions leave the offered comparison unresolved rather than proving a pass or a measured miss. Ten bad requests also do not identify how long service was unavailable. The counts provide no placement of failures within W2, no continuous availability observations and no explanation of their causes. Calling W2 a failed window classifies the interval; it does not establish that its entire ten minutes were an outage. Request failures cannot simply become downtime minutes, lost revenue or service credits. Keep supporting evidence questions with their own guides. Why Sampled AI Traces Do Not Establish the Request Error Rate examines capture and selection coverage. The pooled-latency histogram guide explains evidence for an aggregate latency condition; averaging worker percentiles cannot fill that gap. The cumulative-counter guide addresses interval counts when counters reset. Recovery Point and Recovery Time addresses recovered application state and service return. Those guides can help establish inputs or different outcomes without replacing this article's compliance calculation. ## Read the response policy and SLA separately The SRE Workbook treats an error-budget response policy as something the organization agrees alongside its objective. The numeric balance does not select that response by itself. Ask which team owns the objective and which agreed policy applies to the reported result. The foundational SRE book distinguishes an SLO from a service-level agreement, or SLA, that includes consequences. A calculation against an internal objective does not establish that a contractual commitment was missed or that a buyer is entitled to a remedy. The comparison here supplies no interpretation of a vendor contract. The useful buying result is a reliability statement that can be reproduced from its declared population and rules, together with a separately identified response policy or agreement where applicable. The number of nines alone supplies none of the missing definitions. References: [SRE-WB](https://sre.google/workbook/implementing-slos/), [SRE-TERMS](https://sre.google/sre-book/service-level-objectives/) ## Discuss a physical package only if the decision includes one Evaluating an inference software offer using an existing installed fleet may require no physical equipment project. Reliability objectives and their software evidence remain with the customer's appointed platform teams and providers. If the selected arrangement separately requires equipment receiving, rack integration, agreed hardware QA, onsite installation or IT cabling, Leviathan's Complete Physical Deployment service provides a route to discuss those physical stages as a defined package. Use the related service and project-inquiry links with a nonconfidential equipment configuration, site and intended physical handoff. The inquiry concerns that separately selected equipment package. References: [LEV-PHYSICAL](https://www.leviathansystems.co/services/turnkey-gpu-deployment) ## Primary sources - [SRE-WB — Google SRE Workbook, Chapter 2: Implementing SLOs](https://sre.google/workbook/implementing-slos/). Checked 2026-10-20. 2018 workbook chapter, current web copy checked. Supports good-event ratios, target-derived allowances and a separately agreed response policy. - [CLOUD-SLO — Google Cloud Observability: Concepts in service monitoring](https://docs.cloud.google.com/stackdriver/docs/solutions/slo-monitoring). Checked 2026-10-20. Documentation updated October 13, 2026. Supports request/window units and compliance periods; product configuration limits are not universal SLO rules. - [SRE-TERMS — Google SRE book, Chapter 4: Service Level Objectives](https://sre.google/sre-book/service-level-objectives/). Checked 2026-10-20. Foundational chapter distinguishing indicators, objectives and agreements with consequences. Used for terminology, not current contractual commitments. - [LEV-PHYSICAL — Leviathan Systems: Complete Physical Deployment](https://www.leviathansystems.co/services/turnkey-gpu-deployment). Checked 2026-10-20. Public description of engagement-defined receiving, rack integration, hardware QA, installation and cabling. Applicable physical stages require an agreed scope. ## Related Leviathan resources - [Sampled traces and the observed request population](/articles/ai-observability-trace-sampling-versus-request-metrics) - [Pooled latency histograms and fleet-percentile evidence](/articles/inference-pooled-latency-histograms-versus-worker-percentiles) - [Cumulative request counters and resets before aggregation](/articles/inference-cumulative-counter-resets-before-aggregation) - [Recovery objectives and actual restore observations](/articles/ai-workload-recovery-objectives-versus-restore-observations) - [Complete Physical Deployment for a separate equipment package](/services/turnkey-gpu-deployment) - [Project inquiry for a separately selected physical equipment package](/contact?service=turnkey-gpu-deployment&from=%2Farticles%2Finference-slo-request-window-error-budget-units) ## Does the selected arrangement need a separate physical equipment package? Share a nonconfidential equipment, site and physical handoff outline to discuss installation scope, requirements and availability. [Discuss the scope](/contact?service=turnkey-gpu-deployment&from=/articles/inference-slo-request-window-error-budget-units)