An error spike needs a denominator. Reason with burn rate.

Name the promise before drawing the chart

Suppose an original example service aims for 99.5% successful eligible requests over a reporting period. “Eligible” matters: decide whether retries, health checks, invalid client input and requests blocked before reaching the service belong in the population. A changing denominator can make a chart improve while customer experience gets worse.

Use a request-based indicator here. Do not quietly interpret it as uptime minutes. A minute with ten requests and a minute with ten thousand requests contribute different amounts of traffic, even if they occupy the same length of time.

Work through a small budget

For a fixed illustrative population of 200,000 eligible requests, a 99.5% objective permits 1,000 bad requests. If 250 have already been bad, the remaining budget for that fixed population is 750. This is arithmetic under a chosen population, not a forecast of how many requests the real service will receive.

Now inspect a shorter window. If 2,000 eligible requests include 40 bad outcomes, the observed bad-event rate is 2%. The permitted bad-event rate is 0.5%. Their ratio is 4: the service is consuming its request error allowance four times as quickly per request as the objective permits.

Short-window bad rate	Allowed bad rate	Burn rate
0.25%	0.5%	0.5
0.5%	0.5%	1
2%	0.5%	4

Separate a measurement from a page

Burn rate answers how severe the measured bad-event fraction is relative to the objective. It does not by itself decide who should wake up. A page needs an actionable failure, an owner and a response that can reduce customer harm. An informational dashboard and an urgent alert can use the same metric for different decisions.

Imagine two failed requests out of five overnight. The error fraction is large, but evidence is sparse. Compare that with thousands of failed requests across a sustained busy period. Both deserve investigation, yet the same threshold and timing policy may behave poorly for one of them.

Test the alert as a system

Replay a complete outage, a brief burst, repeated small bursts and a clean recovery. Inspect detection delay and how long the alert stays active after the incident ends. A long averaging window can continue paging after the problem has cleared; an overly short window can react to noise.

Missing telemetry is another state, not automatically zero errors. Check how counters reset, whether denominator and numerator describe the same population, and what happens when there are no eligible requests. Avoid dividing by zero or converting absence into a reassuring green result.

Write the response alongside the threshold

Document the indicator, objective, reporting period, alert windows and response owner. Include a runbook that distinguishes an application regression from an upstream failure or telemetry problem. Use the calculation to support an operational decision. A browser model or a neat percentage does not establish that a production service meets an SLO.