Scheduled traffic spikes from events like ticket presales, sports finals, and product launches keep breaking systems that pass ordinary load tests, because the danger isn't total volume but ramp speed. Ticketmaster's 2022 Eras Tour presale hit 3.5 billion requests in a day, four times its prior peak, and buckled within an hour. Standard load tests miss what matters: how fast autoscalers lag behind vertical ramps, cold caches after deploys, and queues that never drain once retries start piling up. Slack's January 2021 outage illustrates the trap directly - packet loss on an AWS transit gateway lowered CPU usage, and the autoscaler misread that as calm and removed capacity during the year's busiest morning. Guidance for a truthful spike test: compress the ramp to under two minutes, test recovery after the peak fades, model bot traffic, use production-scale data, and measure error rates per endpoint rather than in aggregate.
Questions this post answers
Why did Slack's autoscaler remove capacity during its busiest traffic morning in January 2021?
An AWS transit gateway started dropping packets around 6 AM Pacific on January 4, 2021, causing servers to wait on the network and their CPU usage to drop. Slack's web tier scaled based on CPU usage, so the autoscaler interpreted the low CPU readings as calm conditions and removed capacity during the busiest morning of the year, worsening the outage. Engineers debugging autoscaling metric blind spots can find similar incident breakdowns on daily.dev.
How many requests did Ticketmaster's Eras Tour presale generate and why did the site fail?
The Eras Tour presale generated 3.5 billion system requests in a single day, about four times Ticketmaster's previous peak. The site buckled within an hour because the ramp to that volume happened almost instantly rather than gradually, and roughly 14 million entities (bots included) hit a presale meant for about 1.5 million invited fans. Teams planning capacity for a launch can compare real-world spike incidents like this one on daily.dev.
What should a spike test do differently from a standard load test?
A spike test should compress the ramp to full expected load in under two minutes instead of holding a fixed user count for an hour, test the recovery period after traffic falls (not just the peak), model bot and scraper traffic, run against production-scale data rather than a near-empty database, and measure error rates per endpoint since an aggregate 2 percent failure rate can hide a checkout flow failing 60 percent of the time. Anyone building a spike-test plan for an upcoming launch can track load-testing techniques on daily.dev.