Drain Dashboard¶

A monitor for an active drain — instantiates Queue Draining

The live instrument panel of a drain — remaining backlog, oldest item, throughput, exceptions, and a completion forecast — that tells operators whether the drain is actually reducing risk or just moving work around.

A drain that can't be seen can't be trusted: a falling item count can hide a growing tail of old, hard cases, or a second queue quietly filling elsewhere. Drain Dashboard is the instrument that makes a drain legible in real time — remaining backlog, the age of the oldest item, throughput, exception count, and a completion forecast — and it can raise the alarm that a drain is needed by watching a threshold. Its defining property is that it shows and signals but never acts: it turns a single "queue size" number into the shape of the backlog, so operators can tell risk-reduction from mere motion, but it serves, orders, and disposes nothing itself.

Example¶

A trust-and-safety team moderates flagged posts. Their dashboard shows 42,000 items pending, oldest 9 days, current review rate ≈6,500/day, projected clear in ≈8 days — plus an age histogram and an exceptions counter for items stuck in appeal. During a spike it flips a banner — "oldest item > 7 days" — which is the team's declared trigger to open a dedicated burn-down. The most valuable moment comes a week later: the headline count is dropping nicely, but the histogram's old-age tail is growing. The dashboard reveals that reviewers are clearing easy new reports while the hardest aged cases sit — a distinction the single number completely hid, and the reason the team re-weights its order rule.

How it works¶

Ingest queue telemetry. Count, age distribution, throughput, and exception counts are pulled continuously from the queue.
Render shape, not just size. The age histogram and class mix expose which backlog is draining, so a shrinking count with a fattening old tail is visible rather than reassuring.
Forecast against the target. A projected completion time is computed from throughput — flagged as conditional on inflow, not a promise.
Fire the trigger. When a threshold (age, size, exception rate) is crossed, it raises the signal that a controlled drain should begin.

Tuning parameters¶

Metric set — count-only versus age-distribution + throughput + exceptions. Richer catches hidden queues and stale tails but risks dashboard overload and ignored panels.
Trigger thresholds — the age/size/exception levels that flip the "drain needed" alarm. Tight triggers earlier with more false alarms; loose triggers late.
Forecast model — naïve rate extrapolation versus one that accounts for continuing arrivals. Naïve is simple but over-optimistic whenever inflow hasn't stopped.
Refresh cadence — real-time versus periodic. Real-time suits an active drain; periodic reduces noise for slow-moving backlogs.

When it helps, and when it misleads¶

Its strength is defeating false confidence: it separates risk reduced from count reduced, surfaces new hidden queues (a dead-letter queue filling, an age tail growing), and gives a shared, forecastable picture instead of anecdote.

It misleads when a single count becomes the thing everyone optimises — clearing whatever makes the number drop fastest, which is rarely the riskiest work.^[1] A tidy forecast can also imply a control the team doesn't have if arrivals aren't modelled and the queue is still being refilled. The classic misuse is watching the dashboard instead of acting on it — treating visibility as progress. The discipline is to pair every headline metric with an age/mix view and to read the forecast as "if inflow stays as assumed," never as a commitment.

How it implements the components¶

progress_visibility_signal — the live render of remaining backlog, throughput, exceptions, and forecast.
backlog_inventory — the age distribution and class mix that expose the shape of what remains, not merely its size.
drain_trigger — the threshold alarm that declares a controlled drain should begin.

It has no authority to act: it does not set policy or item order (Message Queue Drain, Graceful Queue Shutdown), allocate capacity (Surge Worker Pool, Backlog Burn-Down), or run the post-mortem on why the backlog formed (Backlog Burn-Down).

Instantiates: Queue Draining — it is the visibility layer that keeps a drain honest and can trigger one.
Sibling mechanisms: Backlog Burn-Down · Surge Worker Pool · Incident Backlog Cleanup · Message Queue Drain · Graceful Queue Shutdown · Connection Draining · Maintenance Drain · TTL Expiration Sweep · Dead-Letter Queue Processing · Appointment Waitlist Clearing

References¶

[1] Goodhart's law — "when a measure becomes a target, it ceases to be a good measure." A drain dashboard's single headline count is exactly the kind of measure that invites gaming; pairing it with an age/mix view is the standard guard. ↩