SYSE.37:5 - Archetypal Grounding
Consider a constructed high-volume software service, separate from the sparse ParcelWorks address-form example. Its users/providers have agreed a 99.9% good-event objective over 30 days and a response policy that treats 2% budget consumption in one hour as an urgent risk.
For the illustrative constant eligible-event-rate basis, T = 720 hours, p = 0.02 and w = 1 hour. The threshold is 0.02 × 720 / 1 = 14.4. Multiplying by the allowed bad fraction 0.001 gives a bad-event threshold of 0.0144, or 1.44%. The selected rule requires that threshold to be exceeded in both the one-hour window and the most recent five-minute window.
| Constructed observation | Rule result and meaning |
|---|---|
| Both windows have a 2% bad-event fraction. | Burn rate is 20 in each window; this urgent condition fires. |
| The one-hour fraction remains 2%, but the recent five-minute fraction is zero with complete observation. | This active fast-burn condition no longer fires; accumulated budget use still exists. |
| The short-window series is missing. | The confirmation is unobserved, not favorable; the telemetry-loss response applies. |
| The metric accidentally includes another service’s successful requests. | The rule no longer measures the agreed subject and must be repaired. |
The recipient’s first qualified action is to inspect the affected task and current service state, then apply the available mitigation under the service’s response policy. The exercise verifies the predicate, notification route and recipient response separately. It does not claim that all incidents or slower budget risks are covered by this single rule.
Now consider a low-volume class with ten eligible attempts in an hour and one failure. Its observed bad fraction is 10%; against a 99.9% objective, the normalized burn rate is 100. This arithmetic does not show that the same high-volume paging strategy fits the case. A single high-consequence failed task may merit direct action; an ephemeral retriable failure may warrant a different, explicitly agreed response.
Synthetic probes can reveal some unavailable paths before a real user arrives, but their successful requests must not erase the real task’s failed observation. If the rare task cannot be represented by the probe, that blind spot remains.
The platform/application distinction also remains intact. A deployment-path alert uses deployment attempts and its objective. An address-application alert uses address-task observations and that application’s objective. Ten successful deployments do not cancel an observed application defect, and unavailable build workers do not automatically spend the running application’s error budget.
What changes in practice is that a notification says which loss needs what response, while absence of usable data and absence of an available responder remain visible failures of the arrangement.