Best Buy's Black Friday 2025 crash: what every retail team can learn about seasonal demand spikes

Black Friday is no surprise. Retailers know it is coming and roughly when traffic will peak, and most engineering teams prepare for months. Even so, on November 28, 2025, Best Buy’s website and app went down for most of ninety minutes during one of the most important trading windows of the year.

No official root-cause analysis was published. The pattern itself is familiar: a predictable calendar peak overwhelms infrastructure that was not tested at the right scale. It is one of the most common and most preventable kinds of outage in e-commerce.

What happened

On the morning of Black Friday, November 28, 2025, Best Buy’s site and mobile app became unavailable to a large share of shoppers. The disruption lasted about 80 to 90 minutes. It began around 9:40 a.m. ET and was largely resolved by 11:50 a.m. ET, according to reporting from the time.

Downdetector logged more than 1,800 problem reports at peak, and roughly 80 percent of them pointed to the desktop website. Best Buy did not publicly release an explanation or postmortem. Reporting at the time blamed the volume of Black Friday morning traffic, but nobody officially confirmed the cause.

The timeline

• ~9:40 a.m. ET, November 28, 2025: Reports about the Best Buy site and app start surging on Downdetector.
• Peak outage window: Downdetector reaches over 1,800 reports; ~80% of complaints are desktop web.
• ~11:50 a.m. ET: Service largely restores, approximately 80–90 minutes after onset.
• No postmortem: Best Buy did not publish a public root-cause statement.

Why it happened

With no official postmortem, any specific technical cause is speculation. Reporting does support one fact: the disruption coincided with peak Black Friday morning traffic, the window when promotional deals go live and millions of shoppers open the site at once.

That timing matters. Black Friday morning traffic does not ramp gradually. Deals are announced in advance and shoppers pre-load pages. When the deals go live, often at midnight or at a posted morning hour, traffic spikes sharply. If the production system was sized for sustained high load but not for that ramp rate, the spike could saturate connection pools, session stores or upstream dependencies faster than auto-scaling can respond.

Failures were reportedly concentrated on desktop web (versus app or mobile). That suggests a partial failure, possibly tied to web-tier infrastructure, a CDN routing issue or a path that desktop traffic uses differently from the app. Without a postmortem, these remain inferences.

For a retail team, an unknown cause does not lower the risk. A predictable calendar peak gives you a predictable chance to find your ceiling before shoppers find it for you.

The failure pattern

This is a seasonal demand spike. It is the easiest category of load failure to address, because the date, rough size and traffic shape are all known in advance. Unlike a surprise viral moment, Black Friday has a scheduled start time and years of comparable historical data.

The pattern reaches beyond retail: tax filing deadlines, enrollment windows, payday Fridays, scheduled results days, product launches with announced times. Any system that serves a predictable annual or cyclical peak is exposed if nobody has tested that peak at realistic scale.

Seasonal spikes are dangerous because surviving previous years breeds false confidence. Each year brings more users, more devices, new code paths and changed infrastructure. Last year’s success does not prove this year’s capacity is enough.

How it could have been prevented

Load-test the real calendar peak, not an average day. Historical Black Friday traffic data (or a conservative estimate above it) should drive the test scenario. Testing at 120–150% of last year’s peak adds reasonable headroom for growth.

Test the full user journey under concurrent load. Storefront reads are usually the easiest path to scale. Login, cart-add and checkout need session state, writes and often third-party calls (payment processors, loyalty APIs), so they saturate earlier. Include them in every Black Friday test.

Test the ramp rate as well as the peak. A system can sustain 100,000 concurrent users at steady state and still fail if 80,000 new connections arrive in 90 seconds. Spike tests that jump to peak in minutes show this. Gradual ramp tests do not.

Pre-scale before deals go live. Auto-scaling that reacts to the spike itself may trail the ramp by minutes, long enough for shoppers to notice. Provision extra capacity an hour before the event and scale down afterward.

Have a rollback plan. If a new feature shipped for the Black Friday window adds to the overload, rolling it back is usually faster than scaling infrastructure.

How to test for this with MaxoPerf

For a seasonal demand spike, run a spike test scaled to your expected Black Friday peak weeks before the event, not days.

Engine: k6 or Taurus (JMeter)

Profile: open-model spike. Ramp from your current daily peak to your Black Friday peak concurrency target over 5–10 minutes (to match the real morning ramp) and hold for 20–30 minutes. Then check whether requests per second throughput stays proportional to load or plateaus. A plateau means you’ve hit a ceiling. Add a second spike at a higher level to test your headroom.

Target: your own staging or pre-production environment, running the full sequence: homepage load → category page → product search → product detail → login/account check → add to cart → begin checkout. Keep the login path in even if your main concern is storefront pages. Session creation is often the first bottleneck under concurrent load.

Locations: use at least two managed cloud regions to model shoppers in different places arriving at once. If your storefront sits behind a private edge or your staging environment is not reachable from the internet, add a private/BYOC location.

What to watch in results:

• Requests per second on the login and cart-add labels. If these plateau while the virtual user count climbs, your session or write path is saturating.
• p95 latency across all labeled flows. A checkout p95 that stays flat until 60,000 virtual users and then doubles shows you where the knee is.
• Error rate by endpoint. Sudden 5xx or timeout spikes on one path narrow the investigation right away.
• Run artifacts for downstream dependency errors (payment tokenization, loyalty lookups, inventory checks).

Failure criteria: set thresholds before the run. For example, the error rate must stay below your tolerance and p95 checkout latency must stay under your agreed limit. MaxoPerf records the pass/fail result, so you have a documented decision as well as a chart.

Schedule this test six to eight weeks before Black Friday. If it shows a ceiling, you have time to fix it with capacity, query tuning or changes to the bottleneck path. Re-run it two weeks out to confirm the fix held.

To add performance checks to your release pipeline in the weeks before Black Friday, see the CI/CD performance gates pattern.

Key takeaways

• Seasonal spikes are the most preventable category of load failure. The date, scale and traffic shape are all known ahead of time.
• Surviving last year does not prove you’ll survive this year, because infrastructure and code keep changing.
• Test the ramp rate as well as the peak. Fast arrival in a new deal window saturates systems differently from a gradual ramp.
• Login and session paths saturate before read-only storefront paths. Include them in every Black Friday test scenario.
• Pre-scaling before the event window is more reliable than auto-scaling triggered by the spike itself.

To test your storefront before the next seasonal peak, run a Black Friday spike simulation on MaxoPerf against your own environment, before your shoppers find your ceiling for you.