Why is the queue still long after the rush?

A surge ends, and yet the backlog doesn't โ€” support tickets after an outage, checkout lines after the match, builds after the merge deadline. The pile grows fast, at everything the rush brings beyond your capacity, but it drains slowly: only the capacity your baseline work leaves over goes to digging out. A team at 50% busy shrugs off a two-hour rush; the same team at 95% busy spends the rest of the week on it. The busier you normally run, the longer the hangover โ€” headroom is recovery speed.

The rush
We can handlejobs per.
Normallyarrive per hour;a surge bringsper hour for.
backlog (jobs)surge ends5101520
04 h6 h7.6 h
The surge ends after 2 h โ€” the backlog ends 5 h later, draining at your spare capacityCapacity minus baseline arrivals โ€” the only rate the pile can shrink at once the rush is over. The rush builds the backlog at full overload speed, but only your leftover capacity digs it out. of 4 per hour. Peak pile-up 20 jobs, worst waitThe wait facing whoever arrives right at the surge's end: the whole peak backlog is ahead of them, served at full capacity โ€” roughly peak รท capacity. โ‰ˆ 1 h โ€” about 70 job-hours of waiting in all.
The hangover
Baseline busySpareRecoveryรท surge
50%10/h
2 h
1ร—
70%6/h
3 h 20 min
1.7ร—
80%you4/h
5 h
2.5ร—
90%2/h
10 h
5ร—
95%1/h
20 h
10ร—

Every row clears the identical surge โ€” 20 jobs deep, built in 2 h โ€” and differs only in how calm the baseline is. At 50% busy the backlog drains in 2 h; at 95% the very same rush takes 20 h to dig out of, 10ร— the surge itself. Utilization looks like efficiency on a quiet day, but headroom is recovery speed: the slack you keep is how fast you bounce back.

a deterministic fluid-model back-of-envelope โ€” backlog builds at ฮปโˆ’ฮผ, drains at ฮผโˆ’ฮป