How do you estimate wait times honestly when traffic spikes 10x?
Why position-based ETAs fail
Position divided by a fixed rate is the naive formula, and it breaks the moment throughput changes. Checkout slowdowns, payment failures, inventory holds, and plain human dawdling all make the drain rate lumpy. A queue showing 12 minutes based on position 400 and a historical rate of 33 per minute becomes 40 minutes when the real rate drops to 10, and every upward revision teaches visitors that the number is fiction.
The revision direction matters psychologically. An ETA that shrinks feels like a gift; an ETA that grows feels like a betrayal, even when both are equally inaccurate. Systems that anchor on optimistic fixed rates systematically produce the betrayal pattern. The fix starts with measuring the actual recent drain rate and letting the estimate move with reality.
Computing the honest estimate
Use a rolling window of recent throughput, typically the last three to five minutes, and convert position to time against that window. Weight recent minutes more heavily so the estimate reacts to real changes without whiplashing on every blip. Add an explicit buffer for variance: multiply by 1.2 to 1.5 depending on how bursty your traffic is, and label it as an estimate, not a promise.
Segment the computation when your traffic is heterogeneous. Mobile checkout flows drain at different rates than desktop; returning customers move faster than new ones. A single blended rate misleads both groups. If your queue supports priority tiers, compute each tier's ETA separately, because mixing them produces a number that is wrong for everyone.
What to show when you cannot know
At the start of a massive spike, honest math may produce absurd or unstable numbers. Do not display them. Switch the UI to progress mode: show position movement, a progress bar of tickets ahead draining, and qualitative status (moving steadily, high demand). People tolerate uncertainty far better than false precision; the research on waiting consistently shows that unexplained, apparently dishonest waits feel longest.
Keep communicating during the wait. Periodic updates, even without new numbers, reduce perceived wait time: your place is held, the queue is moving, here's what's happening. Silence in a queue reads as abandonment. The cheapest improvement most queues can make is not better math but more frequent, honest status.
Keeping the estimate honest after launch
Log every estimate against the actual wait and review the error distribution weekly. Systematic over-optimism means your buffer is too small or your window too long; systematic pessimism means you are sandbagging, which costs conversions. The goal is a calibrated estimator whose errors are symmetric and small, not one that always pleases.
Also watch the edge cases: visitors who rejoin, devices that sleep and wake, and tickets that transfer. Each needs a defined ETA policy, because ad-hoc handling creates the anecdotes that erode trust. Publish the policy internally, instrument the edge cases, and treat ETA accuracy as a product metric with an owner, not a side effect of queue plumbing.
Should you ever show a precise countdown?
Only when throughput is genuinely stable and measured. In volatile conditions, ranges and progress indicators are more honest and produce fewer complaints.
How often should the ETA update?
Every 30 to 60 seconds is the sweet spot. Faster updates feel jittery; slower ones feel abandoned.
Do honest ETAs reduce conversions?
Slightly longer honest estimates convert better than short dishonest ones. Visitors who trust the wait stay; visitors who catch you revising upward leave and tell others.