Error budgets for controlled service degradation

A rejected request still belongs to a user

When a service is overloaded, refusing some work can preserve the work it can still complete. That decision does not make the refused requests disappear from the user experience. Controlled degradation needs both an admission policy and honest outcome accounting: what the service promises to preserve, what it may omit and which unsuccessful requests count against its objective.

Consider a hypothetical shopping service whose checkout path is essential while its recommendation panel is optional. Under pressure, the application might omit recommendations to protect checkout. That can be a legitimate design choice if the reduced experience is defined in advance. Returning an apparently successful response that cannot complete checkout would be a different outcome, even if both responses carry the same HTTP status.

An error budget describes the unsuccessful work allowed by a stated service-level objective. It does not reserve processor time, create memory or increase a downstream system's capacity. Use it to inform reliability and release decisions while designing actual resource controls for overload. Google's SRE guidance treats those as related operating concerns, not interchangeable quantities. ^[1][2][3]

The first question is therefore about the user outcome. Which requests are eligible, what counts as success and over what window is the result evaluated? The second is about resource protection. Where can the service reject, defer or simplify work before it consumes the constrained resource? A good answer to one does not automatically answer the other.

The examples here are conceptual and the chart is calculated, not measured. No production service was load-tested for this article. A team should use its own authorized experiments and operational evidence to choose admission limits, degraded modes and rollout conditions.

Count the outcomes the service actually promises

An SLI measures a selected aspect of service behavior, and an SLO sets a target for that measure. For a request-success objective, define the eligible population and the successful outcome explicitly. The denominator might be valid user requests on a particular path, but that scope must be part of the policy rather than an adjustment made after an outage. ^[1]

For exactly 1,000,000 eligible requests, a 99% success target permits 10,000 unsuccessful requests. At 99.9%, the allowance is 1,000. At 99.95%, it is 500; at 99.99%, 100; and at 99.999%, 10. These values follow directly from multiplying the request count by one minus the target fraction. The selected targets are illustrative policy inputs, not recommendations or observed availability. ^[1][2]

The chart keeps the denominator fixed so the arithmetic can be compared. It does not say that a service receives one million requests in a day, month or any other period. The evaluation window remains a separate part of an actual SLO. A request-based allowance also should not be casually converted into downtime minutes, because request volume and user impact may vary over time.

Define exclusions before measuring the result. Invalid requests, traffic outside a supported contract or deliberately excluded test traffic may need separate treatment. The policy should explain that treatment consistently. Removing overloaded but otherwise eligible requests from the denominator after they fail can make the metric look healthier while concealing the actual user consequence.

Success can require more than a response code. A latency objective, a correct result or an accepted business operation may matter. If checkout reports success before durable acceptance, the selected SLI might miss a failure the business considers serious. Review the measurement boundary with the service owner so the metric corresponds to the commitment being made.

Keep separate objectives separate where that is clearer. A recommendation panel and a checkout operation may have different user expectations and acceptable degradation. Combining them into one undifferentiated success ratio can hide a serious problem on a lower-volume critical path. The right structure depends on the service, but the reason for choosing it should be explicit.

Source. Primary sources ^{[1] [2]}. Reviewed August 28, 2026. Calculated illustration. For 1,000,000 eligible requests, allowed failures equal 1,000,000 multiplied by one minus the SLO target. Targets are examples, not recommended commitments or measured service results.

Method. Calculated illustration reviewed August 28, 2026. Unit: failed requests within a hypothetical population of 1,000,000 eligible requests. Each value equals 1,000,000 multiplied by (1 - targetPercent / 100), calculated using Decimal arithmetic for the displayed targets. The denominator and targets are authored examples used to explain request-based SLO arithmetic. They are not recommended targets, observed availability, incident measurements or evidence that a degraded response satisfies a real service promise.

Accessible table and figure data

Figure 1 accessible table

SLO target percent	Allowed failed requests
99	10000
99.9	1000
99.95	500
99.99	100
99.999	10

Figure 1 accessible table

SLO target percent	Allowed failed requests
99	10000
99.9	1000
99.95	500
99.99	100
99.999	10

Download imageDownload table CSV

Decide what a degraded service can still do

Choose the essential outcome before selecting the technical shortcut. In the hypothetical service, omitting recommendations may preserve the ability to buy an item. Serving a checkout page that cannot accept the order does not preserve the same outcome. The degraded mode should state what remains supported and how a user or calling system can recognize its limits.

Classify work by its role in that outcome. Some work can be omitted, some can be deferred and some must complete before success can be reported. Those categories are application decisions. A background operation may be optional for one user journey but essential for another, so a global label such as noncritical can be misleading without a boundary.

Google's SRE material discusses the tradeoffs involved in reliability and load management. An engineering choice should consider both the cost of attempting all work and the consequences of refusing some of it. There is no source-backed rule that every optional-looking feature should be disabled first or that a fixed percentage of requests should always be rejected. ^[4][5]

Describe degraded output precisely. An API might return an explicit retryable failure, a limited result or a supported deferred-acceptance response, depending on its contract. Those outcomes should not be substituted for one another without reviewing client behavior. A caller that interprets a limited response as complete data can turn availability protection into an integrity problem.

Also identify work that cannot be safely replayed later without context. Deferring an operation changes when it takes effect, which may matter to authorization, deadlines or business rules. A queue is a mechanism for retaining work, not an automatic justification for changing the timing of every operation. The recovery procedure needs to preserve the original intent and evaluate any time-sensitive conditions.

Make the policy usable by operators. State the condition that permits a degraded mode, the authority to enable it and the evidence required to return to ordinary behavior. Without those boundaries, an emergency setting can become an undocumented permanent service change after the immediate pressure has passed.

Reject expensive work before it consumes the bottleneck

Locate the constrained resource. A service can run out of available processing, memory, connection capacity or downstream capacity while another resource appears healthy. An admission control is useful only if it can prevent additional work from consuming the resource that matters. Rejecting at a late stage may leave much of the expensive work already done.

SRE overload guidance describes refusing work to preserve useful processing rather than allowing uncontrolled demand to consume the whole service. The design must distinguish waiting work from actively executing work and consider where queueing becomes harmful. A long queue can preserve requests while increasing latency beyond the point at which their results are useful. ^[3][4]

The before-and-after illustration places an admission decision ahead of expensive processing. It also separates essential and optional paths. This is a conceptual design, not evidence that a particular architecture achieved a measured improvement. In an implementation, the decision point must have enough context to apply the intended policy without becoming the next unprotected bottleneck.

Bounded concurrency and admission rate are related but different controls. The amount of work in flight depends on how long operations occupy resources, not only on how quickly requests arrive. A request type that becomes slower can increase pressure even when arrival rate stays similar. Choose observations that expose the constrained resource rather than relying on a single reassuring traffic graph.

Review fairness between callers as well as the total admitted load. A shared limit can allow one noisy client or request class to occupy the available work slots while others wait. Where the service makes distinct commitments to tenants or operations, the admission policy needs enough identity and classification context to preserve them. This does not imply a universal per-tenant quota; it identifies another condition the service owner should test before describing the policy as fair.

Consider downstream effects before accepting more work. A front-end tier may have capacity while its database or external dependency is saturated. If every accepted request waits on that dependency, expanding the front-end tier may create more concurrent pressure. A useful admission design respects the complete path needed to finish the user outcome.

Avoid treating the policy as a security bypass. Overload should not justify skipping authorization, returning unverified state or sharing another tenant's cached result. A degraded mode must preserve the security properties essential to its remaining function. If the service cannot do that, an explicit failure can be safer than a superficially available response with incorrect authority or data.

Source. Primary documentation ^{[3] [4] [8]}. Reviewed August 28, 2026.

Method. Original conceptual synthesis reviewed August 28, 2026. Unit: qualitative states and relationships. Scope: Error budgets and controlled service degradation. It is not measured performance, prevalence, risk or implementation proof. The proposed design makes a deliberate admission decision before consuming the constrained downstream resource.

Accessible table and figure data

Figure 2 accessible table

Boundary	Before	After
Incoming request	All work admitted	Class and eligibility identified
Expensive processing	Unbounded competition	Bounded admission protects essential work
Optional work	Competes with essential path	Deferred or omitted under declared policy
Outcome accounting	Only completed work counted	Rejected and degraded eligible work reported

Figure 2 accessible table

Boundary	Before	After
Incoming request	All work admitted	Class and eligibility identified
Expensive processing	Unbounded competition	Bounded admission protects essential work
Optional work	Competes with essential path	Deferred or omitted under declared policy
Outcome accounting	Only completed work counted	Rejected and degraded eligible work reported

Download imageDownload table CSV

Make overload controls observable and reversible

An overload mechanism needs a signal, a decision and an action. Envoy's documented overload manager supplies resource monitors, triggers, overload actions and load-shed points. The article uses the stable v1.39.1 documentation as an implementation reference; the unpinned latest documentation reviewed during research pointed to a development build. ^[8]

Do not adopt an example threshold as a universal production value. A documented configuration illustrates how a mechanism is expressed, not the safe operating envelope of every application. The team must understand which resource is measured, how quickly the signal reflects pressure and what the selected action actually refuses or changes.

Define recovery behavior as carefully as activation. A service that rapidly alternates between accepting and rejecting work can create a confusing user experience and unstable load. The control design should describe how pressure is considered sufficiently reduced and how normal admission resumes. The appropriate conditions require workload evidence rather than an invented generic threshold.

Observe user outcomes alongside the control's own state. A mechanism can report that shedding is active while the protected dependency remains unhealthy. Conversely, a resource can recover while users continue receiving failures because another part of the path has not recovered. The operational view should connect the control action to the service outcome it was intended to preserve.

Keep configuration access available to approved operators during overload. If changing or disabling the control requires the same impaired dependency, an otherwise reasonable mechanism can be difficult to manage. Review the authority, auditability and fallback path for those changes without exposing broad administrative access to unrelated identities.

A rollback should restore a known policy, not simply remove every protection. If the new admission rule is too aggressive, disabling it entirely may return the service to uncontrolled saturation. Prepare a bounded alternative and identify the observations that justify the change. Retain the decision so later analysis can distinguish policy error from a changed workload.

Keep deadlines and budget policy connected

Work can become useless before it finishes. If a caller has already exceeded its deadline, continuing expensive processing may consume capacity without delivering the intended result. gRPC's guidance explains deliberate deadline use and propagation under supported behavior. Review both the caller's expectation and the server's handling rather than assuming every request has a suitable deadline by default. ^[7]

A deadline is not an error budget. It constrains a particular operation's useful time, while the error budget describes allowed unsuccessful outcomes over the SLO's window. The two interact when queued or slow work fails its user promise, but they answer different questions and require different evidence.

Retries can add pressure when a service rejects work or times out. The existing retry article covers retry ownership and amplification. An overload design should connect to that policy so clients do not immediately replace every refused request with more attempts. The admission decision and the caller's response to refusal must be considered together.

An error-budget policy can guide decisions about reliability work and change risk. Google's published policy is an example of how a team can make those decisions explicit. It should not be copied as a universal release freeze or treated as permission to consume the entire remaining allowance deliberately. The policy belongs to the service's users, owners and operational context. ^[2]

Alerting should also refer to the selected user-facing measure. SRE guidance on alerting from SLOs provides a framework for observing how quickly failures consume the allowance. A resource alert can help diagnose overload, but it does not replace an outcome-based signal. Conversely, an SLO signal may reveal harm without identifying the constrained component. ^[6]

Preserve both views in the incident record. The user-outcome measure explains the consequence; resource and control observations explain the mechanism and the response. Keeping them connected without conflating them makes it possible to evaluate whether the chosen degradation policy protected the function it was designed to preserve.

Test user outcomes before declaring protection

An authorized load exercise should start with declared request classes and acceptance conditions. Include essential work, optional work and the cases the admission policy is expected to refuse. Record the service configuration, dependency conditions and control settings. Without those inputs, a reported result may be impossible to interpret after the next release.

Measure the outcomes the policy promises. For the hypothetical service, that includes whether checkout remains usable and whether omitted recommendations are represented correctly. Also count rejected eligible requests and any degraded result that fails its declared contract. A test report should not remove unsuccessful users merely to make the protected path look better.

Exercise the transition back to ordinary operation. Verify that deferred work does not immediately recreate the overload and that returning optional features respects the same resource boundary. If asynchronous work is replayed after the event, its rate and stop conditions need their own plan, as described in the SQS redrive guide.

State the limits of the result. A synthetic workload can support a claim about the tested request mix, environment and control configuration. It does not establish capacity under every traffic pattern or guarantee behavior during a different dependency failure. Keep unresolved cases and assumptions next to the result rather than burying them in a generic passed label.

A controlled degradation policy is ready when it names the preserved user outcome, applies admission before the relevant cost and reports unsuccessful eligible work honestly. The error budget then remains useful as an operating decision tool. It is not a way to hide failures, and it is not a substitute for the resources and controls needed to serve the requests that remain.