Skip to content

Saturation Dashboard

Monitoring dashboard — instantiates Saturation Avoidance

Displays the signals of a flattening response curve — marginal output, latency, errors, abandonment, fatigue — so approaching saturation is seen while there is still time to act.

A channel rarely announces that it has saturated; it just quietly stops converting extra input into extra output while intake keeps flowing. Saturation Dashboard is the instrument that makes that flattening visible — it tracks not how much is coming in, but whether each additional unit is still producing useful response, and surfaces the leading signs (rising latency, errors, abandonment, fatigue, declining conversion) before the curve goes flat. Its defining move, and what separates it from an ordinary utilization gauge, is that it foregrounds the marginal response — the slope, not the level — because a channel can be at 95% "busy" and still fine, or at 70% and already past its knee.[1] It watches the primary channel, and it watches wherever demand was pushed to, so a fix in one place does not silently saturate another.

Example

A hospital emergency department has a wall monitor that used to show one number: patients in the waiting room. It told the charge nurse nothing about whether the department was still working. A Saturation Dashboard replaces it with the signals that actually track saturation: median time-to-first-provider, boarding hours (admitted patients still holding in the ED), and the left-without-being-seen rate — a real, watched crowding metric. When the LWBS rate begins to tick up while arrivals are flat, that is the marginal signal: the department is now converting fewer arrivals into completed care per hour, even though it hasn't "failed."

Crucially, the dashboard also carries a secondary panel: when the ED diverts ambulances to the hospital across town, it plots that hospital's boarding and diversion status too. Two weeks in, the panel catches the failure everyone misses — the ED looks better because its own numbers eased, but the receiving hospital is now itself tipping into saturation. The reroute worked locally and moved the problem, and only the secondary check makes that trade honest.

How it works

  • Track slope, not just level. Plot marginal response (output, conversion, quality per additional unit of load) alongside utilization, so a plateau is legible even when raw volume still looks healthy.
  • Lead with early signals. Prefer indicators that bend before collapse — queue-wait, error rate, abandonment, fatigue proxies — over lagging ones like total failures.
  • Watch the downstream too. Instrument the alternate channels and teams that absorb diverted demand, so secondary saturation shows up on the same screen as the primary relief.
  • Show proximity, not just status. Render each signal against its capacity threshold so "how close to the edge" is the headline, not a value in isolation.

Tuning parameters

  • Signal set — which of latency / errors / abandonment / fatigue / conversion are shown. Too few and a real saturation mode is invisible; too many and the dashboard itself becomes noise no one reads.
  • Marginal window — the time or volume window over which the slope is computed. Short windows react fast but jitter; long windows are stable but late.
  • Aggregation grain — one channel-wide number vs. per-segment (per team, per shift, per region). Fine grain catches a saturated pocket inside a healthy average; coarse grain is simpler to watch.
  • Secondary-scope breadth — how many downstream channels the secondary panel tracks. Wider catches burden-shifting; too wide dilutes attention.

When it helps, and when it misleads

Its strength is early, shared sight: it converts "we're swamped" into a specific, watched slope, and its secondary panel is often the only thing that catches burden being shoved downstream rather than resolved. It gives every other mechanism its trigger evidence.

It misleads in two ways. First, a dashboard detects but never acts — a beautiful saturation display next to no cap, no reroute, and no expansion authority is theatre; teams routinely watch a channel saturate in high resolution and change nothing. Second, the wrong metric mimics the right one: raw utilization or intake volume feels like a saturation signal but isn't, and a dashboard built on level rather than slope will read "green" right up to the knee. The discipline is to wire each signal to an owner and a pre-agreed action, and to keep at least one true marginal metric on the board rather than a wall of level gauges.

How it implements the components

Saturation Dashboard fills the archetype's detection components — the sensing layer, and only that:

  • saturation_signal — its core display: the leading indicators that a channel is nearing its plateau.
  • marginal_response_metric — it tracks whether one more unit of input still yields useful additional response, the diagnostic that separates productive load from saturation.
  • secondary_saturation_check — its downstream panel monitors the channels absorbing diverted demand for secondary saturation.

It does not set the limits it plots against — capacity_threshold, saturation_budget, and the channel model are Channel Capacity Management's — and it takes no action; capping is Frequency Cap's and rerouting is Alternate Pathway Routing's.

References

[1] In queueing theory, mean wait time rises sharply as utilization approaches 1 (the "knee" of the utilization curve, formalized by Kingman's approximation). This is why watching the marginal response slope beats watching a busy-percentage: the channel degrades well before it reads "100% used." ↩