Incident-Rate Freeze Rule¶
Circuit-breaker rule — instantiates Over-Scaling Guardrail
Automatically freezes expansion the moment incidents, errors, or safety events breach a ceiling, holds growth while the system stabilizes, and defines the recovery evidence required to lift the freeze.
An Incident-Rate Freeze Rule is a reactive circuit-breaker: it watches a running incident signal — outages, error rate, safety events, complaints, defects escaped — and when that signal crosses a ceiling, it automatically halts further expansion and puts the system into stabilization until the signal recovers. Its defining property is that it is triggered by a breach, not consulted before a step. Where a precondition rule asks "is quality good enough to grow?" before advancing, this rule sits armed in the background and trips the instant harm accumulates too fast, freezing growth already in motion. It is deliberately mechanical: a defined trigger, an immediate freeze, a stabilization action, and — the part that separates a guardrail from a panic button — explicit restart criteria so the freeze is a temporary hold with a defined way out, not an indefinite stop.
Example¶
A cloud SaaS platform is rapidly onboarding new tenants onto shared infrastructure. Its Incident-Rate Freeze Rule is wired to reliability: the service runs against an error budget — a small allowed quantity of failed requests over a rolling window — and expansion is coupled to it. During one aggressive onboarding push, the new load pushes latency and error rates up until the budget for the window is exhausted. The rule trips automatically: no new tenant provisioning until reliability recovers. The freeze is paired with a stabilization action — shed non-essential background load, add capacity to the strained service, and pause the onboarding queue — and with restart criteria: two clean weeks inside the error budget before provisioning resumes. Crucially, the freeze is not a verdict that the platform is bad or a punishment for the team; it is an automatic hold that converts an accumulating reliability problem into a stop-and-fix instead of a slow slide into a major outage, with a clearly defined path back to growth.
How it works¶
What distinguishes the rule is that it reacts to a breach with a freeze, a fix, and a defined way back:
- Arm a trigger on a live signal. Set the incident measure and the ceiling that trips the freeze — an error budget, an outage count, an adverse-event rate over a window.
- Freeze on breach, automatically. When the ceiling is crossed, further expansion halts without a meeting; the trip is mechanical, so pressure cannot talk it down in the moment.
- Stabilize, don't just stop. The freeze is paired with a defined stabilization or rollback action — shed load, add capacity, revert the last increment — that works the incident rate back down.
- Define restart criteria. The freeze lifts only on stated recovery evidence (a clean window, root cause closed), so it is a temporary hold, never an accidental permanent stop.
The rule reacts to a breach and manages recovery; it does not set a forward quality floor as a precondition for advancing.
Tuning parameters¶
- Trip threshold — how high the incident rate may climb before the freeze fires. A low threshold catches trouble early but trips on noise; a high one avoids nuisance freezes but lets harm accumulate.
- Measurement window — the period the incident signal is summed over. Short windows react fast but are jumpy; long windows are stable but slow to trip on a genuine surge.
- Freeze scope — whether the freeze halts all expansion or only the affected surface. Broad freezes are safe but costly; narrow ones keep unrelated growth moving but risk missing a shared root cause.
- Restart bar — how much clean recovery evidence lifts the freeze. A demanding bar prevents premature restart and thrash; too demanding, and the system stays frozen long after it has actually healed.
When it helps, and when it misleads¶
Its strength is speed and impartiality: an automatic trip removes the "let's push through this quarter" temptation exactly when incidents are climbing, and by requiring a stabilization action plus restart criteria it turns a scare into a controlled stop-and-recover. The pattern is the error budget discipline from site reliability engineering, where exhausting the budget of tolerated failures automatically halts feature or growth work until reliability is earned back.[n1]
Its failure mode is lagging-indicator blindness and its opposite, over-tripping. Wired to a signal that only moves after real damage, the freeze fires too late to prevent the harm; wired too sensitively, it trips on ordinary noise and teams learn to route around it or quietly raise the threshold — cap evasion by another name. A freeze with weak restart criteria can also become an indefinite stop that no one owns lifting. The discipline that keeps it honest is to trigger on the earliest signal that reliably predicts harm, protect the threshold from being loosened under pressure, and always pair the freeze with a concrete stabilization action and stated restart evidence.
How it implements the components¶
Incident-Rate Freeze Rule fills the reactive-brake slice of the archetype's machinery:
holdback_rule— it is the holdback: a defined trigger, authority, freeze, and restart condition that halts expansion the moment the incident ceiling is breached.stabilization_or_rollback_path— the freeze is coupled to a concrete recovery action (shed load, add capacity, revert the last increment) that works the incident rate back below the ceiling.quality_indicator— it reads a running incident/reliability signal (error budget, outage count, adverse-event rate) as the live measure that arms and trips the freeze.
It does not set a forward quality floor as a standing readiness precondition (scale_readiness_criteria — that is Quality-Before-Growth Rule); this rule reacts to a breach in motion rather than gating the next step in advance.
Related¶
- Instantiates: Over-Scaling Guardrail — the rule is the automatic brake that halts and stabilizes when incidents outrun readiness.
- Sibling mechanisms: Rollout Cap · Franchise Growth Limit · Hiring Pace Limit · Site Readiness Assessment · Governance Maturity Check · Quality-Before-Growth Rule · Pilot Expansion Ladder · Scale Gate · Staged Expansion Review
Editorial Notes¶
Form Classification¶
Form family: Control, Automation & Runtime
Rationale: Incident-Rate Freeze Rule operates as a live operational control that automatically routes, enforces, adapts, or responds during execution because it automatically freezes expansion the moment incidents, errors, or safety events breach a ceiling, holds growth while the system stabilizes, and defines the recovery evidence required to lift the freeze
Independent corroboration: The frozen evidence defines Incident-Rate Freeze Rule as 'Automatically freezes expansion the moment incidents, errors, or safety events breach a ceiling, holds growth while the system stabilizes, and defines the recovery evidence required to lift the freeze', so its operative form is Control, Automation & Runtime.
Review outcome: Independent reviewer agreement; high confidence.
Origin Attribution¶
Primary origin: Computer Science & Software Engineering
Origin pattern: Single lineage
Present-day reach: Multi-domain
Rationale: Automatically halting feature or growth work when an error budget is exhausted is canonical site-reliability engineering.
Related originating lineages:
- Engineering & Design — Safety interlocks and stop-work limits independently couple fault rates to automatic shutdown.
- Organizational & Management Science — Growth governance materially extends the freeze to expansion decisions.
Review resolution: Both reviewers independently assign computer_science as the primary originating domain, so that shared primary is retained. Alternate domains are the union of reviewer-identified formative or independently originating lineages; later application settings alone are excluded. The evidence describes one principal historical lineage. It has established independent use across several domains, but that does not make it domain-free. The encyclopedia entry makes that composition explicit.
Encyclopedia synthesis: The exact catalogued form synthesizes established practice rather than reproducing a single standard historical label.
Review outcome: Reconciled after independent review; high confidence.
Notes¶
[n1] An error budget is the quantity of failures a service is allowed within a reliability target over a window; in site reliability engineering, exhausting the budget automatically halts feature or growth work until reliability is restored. It is the canonical example of coupling an incident signal to an automatic freeze with a defined way back. Named here as the lineage of the incident-freeze idea, not as a source of any figure. ↩