Across an estate of hundreds of streams, which broker alert conditions should a platform team own centrally, which must each stream owner set, and what happens to a stream whose owner sets none?

## The question behind the question: whose fact is the number? Ownership arguments about alerting usually get stuck on who is on call. The productive cut is different: for each condition, ask whether the correct threshold is derivable from the cluster or only from the workload. | Condition class | Correct value depends on | Owner | If the wrong party owns it | |---|---|---|---| | Cluster health - shortfalls, unserved partitions, coordination-plane state | The cluster's own configuration | Platform team | Hundreds of teams each guessing at a fact that has one answer | | Node capacity - free space, handle headroom, request wait time | The hardware and the node's limits | Platform team | Nobody notices the volume filling until writes stop | | Flow - reader lag, delivery interval, backlog age | The stream's downstream commitment | Stream owner | The platform pages on a number it has no basis for choosing | | Estate hygiene - streams with no reader, no owner, no threshold | The governance rules | Platform team | Orphans accumulate silently | The first two classes are one number each, written once. The third cannot be, and that is the whole argument. ## Why a single estate-wide flow threshold is wrong Take the most common proposal: one reader-lag threshold for every reader group in the estate. - A nightly batch reader is *supposed* to be millions of records behind for six hours. The estate threshold either fires on it every night or is set so high that nothing else in the estate can ever reach it. - A payments reader is in trouble at a few seconds of staleness. The same number that leaves the batch reader alone leaves this one unmonitored entirely. - A stream whose traffic varies tenfold between business hours and the weekend has two normals of its own, so even one stream can defeat a single number. The number is not a technical parameter with an unknown value. It is an expression of a commitment - the report that must be ready by half past six, the payment that must be visible within a few seconds - and only the owner of that commitment holds it. A platform team that sets it anyway is guessing on behalf of a business it cannot see. ## What the platform owes the owner Requiring a number is only fair if setting one is possible. The platform side of the contract has three parts: 1. **Publish the signal, per stream and per reader group**, with a documented meaning and enough history that an owner can see the stream's own normal before choosing a line. Without per-stream history, every owner is inventing a number. 2. **Supply the condition's shape, not just the signal.** The owner supplies the threshold and the deadline; the platform supplies the template that already contains a sensible sustained window, a stance on missing data, and a floor under any trend clause. Letting every team invent the shape as well as the number is how an estate ends up with four hundred subtly broken rules. 3. **Record the justification with the threshold.** A number whose reason is lost cannot be raised, lowered or defended, and it will outlive the service it was chosen for. ## The default for a stream nobody has set a number for There will always be streams whose owner never supplies one. The tempting answer - apply an estate default and page on it - is the worst available, because it generates pages against a number nobody chose, for a team that has not agreed to receive them, and it teaches the estate that pages are noise. A better default has three parts: a condition that files rather than pages, so the stream is not entirely dark; an explicit record that the stream is unmonitored for flow, so nobody believes otherwise during an incident; and the stream's appearance on a list the platform team reviews. Absence of a threshold is a governance finding, not an alerting one, and treating it as such keeps it visible instead of hiding it behind a fake page. ## Keeping it from drifting Thresholds rot in predictable ways: traffic grows past a record-count number, a commitment moves and the deadline does not, a service changes hands and its rules do not. Two cheap habits help. Prefer age-based flow thresholds to count-based ones, because age survives throughput growth and expresses the commitment directly. And review flow thresholds at the moments the estate already notices - when a stream changes owner, and when its traffic shape changes materially. ## What varies across platforms Which signals the platform can publish per stream differs sharply. Some expose lag per reader group and per partition; some expose only a coarse per-queue depth; a rented cluster may publish a fixed set of numbers and nothing else, in which case the flow condition has to be measured by the application rather than by the platform - and the contract has to say so honestly rather than promising a signal that does not exist.