Skip to content

Capacity Headroom Alert

Monitor — instantiates Conserved Reservoir-Flux Balancing

Watches each reservoir's level against its capacity and fires before the headroom runs out, turning a slow fill or drain into a warning with lead time to act.

A Capacity Headroom Alert continuously compares a reservoir's current level against its capacity ceiling (or floor) and raises a warning while there is still headroom to respond — typically by projecting the current fill-or-drain rate to an estimated time-to-full or time-to-empty. The idea that makes it this mechanism: it is neither a display of the level (that is the dashboard) nor a corrective action (that is the valve rule). It is purely the threshold-and-lead-time tripwire on headroom, and its whole value is the lead time it buys. Its defining refinement is firing on the projected time to the limit rather than the raw level, so a fast-filling reservoir alerts earlier than a full-but-static one.

Example

A SaaS company's primary database sits on ≈4 TB of provisioned disk. The alert tracks used bytes (the level signal) and the recent growth rate, projecting a "days-to-full." One quarter a logging change quietly doubles write volume. The raw level is still only 82% — a level-only alarm would stay silent — but the burn-rate projection collapses days-to-full from ≈40 to ≈6. The alert fires on the rate, buying the week the team needs to add capacity or throttle the new logging before writes start failing in production. The same monitor watching a floor rather than a ceiling would warn a warehouse that a fast-moving SKU will stock out in days, not that it is merely low today.

How it works

  • Maintain a headroom profile per reservoir — the ceiling, the floor, and the safe band between them.
  • Read the current level and its rate of change, not just the instantaneous value.
  • Fire on projected time-to-threshold, so a reservoir approaching its limit fast alerts before one sitting high but stable.
  • Escalate by severity band (warn → page) so the lead time given matches the urgency.

Tuning parameters

  • Threshold placement — how much remaining headroom trips the alert. Tighter thresholds give more lead time but more false alarms.
  • Rate-vs-level trigger — alert on absolute level, on projected time-to-limit, or both; the rate-based form is what catches a sudden change in regime.
  • Smoothing window — how much history feeds the rate estimate. Long windows are stable but slow to notice a new burn rate; short windows are jumpy.
  • Hysteresis — the gap between the fire and clear thresholds, set to stop the alert flapping around the line.
  • Escalation banding — how many severity tiers exist and the lead-time target each promises.

When it helps, and when it misleads

Its strength is converting a slow, invisible accumulation or depletion into an actionable warning with genuine time to respond, and — in its rate-based form — catching a regime change that the raw level would hide until nearly too late.

It misleads when thresholds are set as low as possible "to be safe": the monitor then fires constantly, responders learn to ignore it, and alert fatigue[1] buries the one alert that mattered among the noise. A level-only trigger misses a sudden burn-rate change; and an alert wired to no owned response is not a safeguard, only more noise. The discipline is to tie every alert to a defined response and tune each threshold to the actual lead time that response needs, not to the lowest number that feels prudent.

How it implements the components

Capacity Headroom Alert realizes the detection side of the machinery — the level-against-limit tripwire, nothing downstream of it:

  • capacity_and_headroom_profile — holds each reservoir's ceiling, floor, and safe band; the reference the level is judged against.
  • stock_level_signal — reads the current level and its rate and thresholds them into a timed warning.

It does not measure or render the full inflow/outflow picture on a live board (inflow_outflow_rate_measure) — that's Reservoir Balance Dashboard; and it takes no corrective action once it fires (flux_intervention_lever_catalog) — that's Flow Gate or Valve Rule, which consumes this alert as its trigger.

  • Instantiates: Conserved Reservoir-Flux Balancing — the alert is the archetype's early-warning layer on a reservoir approaching its bound.
  • Consumes: Material Flow Analysis supplies the reservoir inventory and capacities the alert watches.
  • Sibling mechanisms: Flow Gate or Valve Rule · Reservoir Balance Dashboard · Material Flow Analysis · Mass-Balance Table · Compartment Model · Data Lineage Balance Check · Inventory Reconciliation Workflow · Loss-Sink Audit · Sankey Flow Map · Stock-and-Flow Diagram · System Dynamics Simulation · Unit Conversion Crosswalk · Water or Resource Budget

References

[1] Alert fatigue — when monitors fire so often, or so far ahead of any real problem, that responders habituate and dismiss them, so the alert that finally matters is ignored with the rest. It is the characteristic failure of threshold monitors and the reason thresholds must be pegged to a real response time rather than minimized. ↩