One message, up to ten URLs: the wrong denominator invalidated every threshold downstream

A proxy you chose can be repaired. If every message carried exactly ten URLs, the fix would be arithmetic: multiply the thresholds by ten, relabel the objective, and the accumulated baseline survives as a conversion. The write-up supplies the one observation that closes that door: five messages, twenty-six units of work, and no constant ratio between them ^[5].

Work out the range. Batches run up to ten URLs ^[2], so a reading of five messages covers anything from five to fifty downloads, a tenfold spread behind an identical number on the dashboard ^[1]. The sampled batch averaged 5.2 URLs per message, roughly half the maximum ^[2], which constrains nothing about the next five messages. An alert denominated in messages is not a biased estimator of download throughput. It is an unbiased estimator of something nobody was on call for.

That is the part worth separating from ordinary metric error. Nobody weighed per-download instrumentation against a cheaper message count and picked the cheaper one; the fan-out was not known to the person who wrote the rule ^[3], so the tradeoff never reached anyone's desk. And the number stayed plausible the whole time, which is why review did not catch it. Thresholds, the SLO, and months of "is this number normal?" all inherited the same denominator ^[4].

The other three lessons in the same piece are the same defect in different units. A floor rule, fewer than N items in M minutes, is denominated in throughput while the question is whether work is moving, so on a nightly batch it fires every night: a floor cannot tell wedged from idle ^[6]. Age of the oldest queued message is denominated in waiting time, which is what the intent was about. Nothing queued means nothing to be old, and age climbs whether the consumer crashed or is running and not consuming, which a liveness check will not see ^[7]. In one incident the floor fired seventeen hours out of twenty-four and the age signal fired once ^[8]: the floor spent 71 percent of the day paging ^[3].

The SLO case is the same arithmetic with a guard bolted on. A 99 percent target means one failure breaches any window holding 100 units or fewer ^[11], so an hour with three items and one failure reads as 67 percent and pages ^[12]. The SLI did carry a no-data guard, `> 0` on the rate ^[13], but that excludes exactly one case, the empty window; four items clear it and mean nothing ^[14]. The guard admits windows of one unit where the target needs 101 before a single failure stays inside budget, a gap of two orders of magnitude in the denominator ^[4]. Over a clean fortnight one service breached twelve times ^[15], about one page per 28 hours of rota ^[5].

The API deadline is the only place in the account where the tradeoff was actually priced. About ten requests crossed ten seconds in a fortnight, everything else fast ^[9], so the deadline went to thirty seconds and the alert now means stuck rather than slow ^[10].