Peak Season: Load Testing and an Emergency Plan for Your Shop

Peak season in online retail has been in the calendar for months: the autumn promotion days of the large marketplaces in mid-October, Black Friday on 27 November 2026, Cyber Monday on 30 November and then the Christmas business right up to the final delivery week. And yet shops stumble on exactly those days every season. On Black Friday 2024, traffic ran about twice as high as on a normal October day (Queue-it), and across the customer base of fulfilment provider Stord the maximum daily order volume rose by 252 percent over the same promotion weekend (Stord). If you only notice on the promotion day that the database blocks at a few thousand concurrent sessions, there is no time left to think. This article shows how to derive a realistic load profile, run a staged load test, define thresholds and build an emergency plan from them that holds up when the numbers leave the expected range.

Why peak season is predictable - and still catches shops out

Unlike a hardware failure in July, peak season is not a random event. The dates are fixed, the campaigns are budgeted, the goods are ordered. The preparation window for the technical side therefore sits between July and September - long before the first adverts go out. The volume shows how much rides on these weeks: in the 2025 Christmas business, online retailers in the United States took 257.8 billion US dollars, up 6.8 percent on the previous year (Adobe Analytics). The European market follows the same seasonal logic, even if the absolute figures are smaller.

What surprises shops is rarely the date, then, but the shape of the curve. Revenue does not spread evenly across 24 hours: a newsletter, a countdown or a campaign launch at midnight pushes a substantial share of the day's demand into a window of a few minutes. On Black Friday 2024, traffic additionally grew by 5.3 percent against the previous year (Queue-it). What counts technically is not the daily average but the minute with the highest concurrency. If you want to design the infrastructure elastically for that, the groundwork is covered in the article on auto-scaling for traffic peaks. This text starts one level earlier: with the measurement that tells you how much capacity is actually needed.

What an outage during peak season costs

In 2024, one minute of unplanned downtime in organisations with at least 1,000 employees cost an average of around 14,056 US dollars (BigPanda/EMA). For 90 percent of medium-sized and large companies, a single hour of downtime costs more than 300,000 US dollars (Information Technology Intelligence Consulting). Such averages cannot be transferred one to one to a mid-sized shop - but the underlying arithmetic can. Your own figure comes from the planned revenue of the peak hour divided by 60, multiplied by the expected duration of the outage, plus the advertising budget burned in that window and the additional effort in customer service.

The more expensive part of the calculation, however, does not appear in the daily report. 64 percent of customers trust a shop less after a crash (Queue-it), and a substantial share do not return after a poor experience caused by downtime or slowness. A promotion day attracts an above-average share of first-time visitors - people with no attachment to the brand who simply move on when they see an error message. The damage therefore reaches well beyond the day itself. Continuous shop monitoring for uptime and performance at least makes such dips visible before customers report them.

The load profile: the basis of any meaningful test

Before the first test run comes the question of what exactly is being tested against. A load test with freely chosen user numbers produces pretty charts and no insight. It only becomes meaningful once the load profile is derived from real data. These data sources provide the basis:

• Last year's web analytics: sessions, page views and orders in minute-level detail for the promotion days - not as a daily total but as a curve.
• Server logs: requests per second by page type. Category, product and checkout pages behave completely differently in technical terms.
• Campaign plan: send times for newsletters, planned countdowns, start times of discount promotions. Each of these dates creates a peak of its own.
• Assortment data: promotional items with many variants or elaborate filters put more strain on the database and the search index than the rest of the catalogue.
• External dependencies: payment providers, shipping services and the merchandise management system have limits of their own that belong in the test.
• Bot share: price comparison services and crawlers intensify their access during the promotion week and belong in the load profile, even though they generate no revenue.

These values produce a planning figure per metric. A two-step approach has proven practical: first take the measured value of a normal day, then apply the peak factor to it. As guidance for that factor, use the doubling of peak day traffic against a normal October day observed in 2024 (Queue-it) and the rise in maximum daily order volume of 252 percent in the same year (Stord). The following table is a worked example; in your case the column with measured values comes from your own analysis.

Setting up the load test: environment, scenarios, stages

A load test is only as meaningful as the environment it runs in. Testing happens against a production-like copy: same shop version, same extensions, comparable data volume in the catalogue and the same cache configuration. A system with a thousand test articles behaves differently from one with a grown assortment. In hosting and ongoing maintenance, such a copy can be kept available at reasonable effort and reset to the same starting state for every run. Only then are two runs comparable at all.

In terms of content, the test reproduces the real customer journey, not just the home page. A usable scenario mixes entry pages, category views with filters, product detail pages, search queries, cart actions and a share of completed orders. The checkout is the most demanding path and at the same time the one that counts on the peak day. The load is then raised in stages so that it becomes visible at which point the curve tips over:

1. Warm up: five minutes at low load so that caches and connections reach a realistic state.
2. Ramp up in stages: increase the user count in fixed steps and hold each stage for at least five minutes - short bursts hide slowly growing problems.
3. Hold the planning figure: run the determined peak day planning figure steadily for half an hour. Only this sustained load reveals memory leaks and queues filling up.
4. Go beyond the planning figure: keep increasing until a threshold breaks. The breaking point found this way is the actual capacity ceiling.
5. Ramp down: lower the load again and check whether the system recovers on its own or needs a restart.
6. Follow up: evaluate logs, database statistics and queues while the measurement data is still fresh.

# Stage plan for the peak season load test
scenario: peak day simulation
environment: production-like copy, same version and data volume

measurement_points:
  - category page with filter
  - product detail page
  - search
  - cart
  - checkout completion

distribution:
  category: 40
  product: 30
  search: 15
  cart: 10
  checkout: 5

stages:
  - users: 500
    duration: 5m
  - users: 1000
    duration: 5m
  - users: 2000
    duration: 5m
  - users: 4000
    duration: 5m
  - users: 6000
    duration: 30m # hold the planning figure
  - users: 8000
    duration: 5m
  - users: 10000
    duration: 5m

abort:
  response_time_p95: 2.5s
  error_rate: 1%
  checkout_errors: 0.5%

Repeatability matters. Every run should start at the same time of day, with the same data state and the same scenario. Only then does a second run after a change actually say something about the effect of that change. A single test delivers a snapshot, a series of tests delivers a curve - and the curve is what counts in planning.

Defining thresholds: target, warning, emergency stop

A load test without predefined thresholds ends in a debate about whether 1.8 seconds is still acceptable. That debate belongs before the test, not after it. Three values are enough, and they should be written down and agreed with the business side. The same values later become the triggers in the emergency plan - which is why it pays to choose them so that a concrete action belongs to each one.

Alongside response time, two further metrics belong in the threshold set: the error rate and the saturation of limited resources. Saturation covers occupied database connections, processor core utilisation, free memory and queue lengths. These values typically rise before response time reacts visibly - they are the early warning system. How to systematically improve pure delivery speed is the subject of PageSpeed optimisation; in a load test the question is how long that speed holds under pressure.

Bottlenecks a load test makes visible

In practice the findings repeat themselves. It is rarely exotic faults that slow a shop down on the peak day, but a handful of familiar patterns that simply do not show up in everyday operation because the load is too low for them:

• Database connections: the connection limit is reached before the processor or memory hits its ceiling. Requests then wait for a free slot instead of for compute time.
• Collapsing cache hit rate: personalised elements, customer group prices or cart components bypass the page cache. On a promotion day with many logged-in customers, the hit rate drops exactly when it is needed - a case for cleanly designed Redis caching in Shopware.
• Backed-up background processes: order confirmations, stock synchronisation and index updates run through queues. If the workers in production are not sufficient, the backlog grows quietly until confirmations arrive hours late.
• Search index and filters: elaborate filter combinations on promotional categories generate considerably more load than a simple product page and hit the index particularly hard.
• Images and media: uncompressed product images in promotional banners multiply the transfer volume exactly when the line is already full.
• External interfaces: payment providers, shipping services and merchandise management have limits of their own. Particularly complex cases such as freight shipping for bulky goods with freight calculation in the checkout deserve dedicated attention in the test.
• Mail dispatch: a rush on the order path creates a rush on the mail outbox. How to set up the order confirmation as a revenue channel without overwhelming dispatch on the peak day is worth a separate look.
• Logs and disk space: verbose logging under load fills storage faster than expected. A full file system brings a shop down just as reliably as an overloaded database.

The emergency plan: escalation stages instead of improvisation

The load test says when things get tight. The emergency plan says what happens then. The two belong together, because a threshold without an attached action is just a number on a screen. A usable plan fits on two pages, is available in printed form and names an action, a responsible role and a time window for each stage. This structure has proven itself:

1. Roles and availability: who decides, who implements, who informs customers? With names, phone numbers and a named deputy per role.
2. Stage 1 - observe: the target value is being held. The on-call staff watch a defined set of metrics without intervening.
3. Stage 2 - open the relief valves: from the warning threshold onwards, prepared relief measures are activated: pause non-critical background jobs, switch off recommendation modules and elaborate filters, deliver images at lower resolution, reduce logging.
4. Stage 3 - emergency stop: from the emergency threshold onwards, controlled reduction takes effect: a waiting room in front of the shop, a lean mode with simplified pages, if needed the temporary shutdown of individual features in favour of the order path.
5. Communication: a prepared status message, an agreed text for customer service and a short notice in the shop. Silence costs more trust than an honest maintenance message.
6. Way back: for every measure it is settled how it gets reversed. A lean mode that nobody switches off after the promotion day becomes a problem in itself.
7. Restart: for the most severe case, the procedure from the emergency plan for backup and recovery applies - with tested backups and a rehearsed restart.
8. Log: who did what and when is written down. The log is the basis for the review and for planning the following year.

The term relief valve deserves an explanation, because it often stays too abstract in planning. It refers to features that are useful in normal operation but dispensable under full load: product recommendations, rating stars from an external source, live stock levels on overview pages, elaborate faceted filters, animated banners. Each of these features costs compute time or an external request. If they can be deactivated with a switch and that switch has been tested in advance, the shop gains margin in an emergency without touching the order path.

The operating calendar up to the peak day

Load testing and an emergency plan are not tasks for a single week but a sequence spread over several months. The reason is simple: implementation time sits between the first test, the rebuild and the retest, and a rebuild without a retest is a bet. The following sequence transfers to most shops:

One point deserves particular attention: the change freeze. From roughly two weeks before the first promotion day, no functional changes go live - no new extension, no rebuild of the category structure, no switch of payment provider. Security updates are exempt; everything else waits until January. Anyone planning a relaunch in that period is better off postponing it: even a clean redirect plan for a relaunch needs observation time that nobody has during peak season. Delivery itself should also be settled before the freeze - a workable CDN strategy for online shops belongs in September, not in the promotion week. How much the season weighs overall is shown by the Christmas volume of 257.8 billion US dollars in US online retail alone (Adobe Analytics).

Plan capacity instead of hoping for it

Peak season rewards preparation and punishes assumptions. A shop that knows its capacity ceiling, has written down its thresholds and keeps a rehearsed action ready for each threshold enters the promotion day with considerably less risk than one hoping for a quiet weekend. The effort required is manageable and falls into a period in which retail plans anyway. What matters is that measurement, threshold and action belong together - a number without a consequence helps nobody on the peak day.

Whether Shopware, WooCommerce or an individually developed solution: the procedure stays the same - measure, find the ceiling, set thresholds, rehearse the actions. For Shopware projects, our work as a Shopware agency brings the knowledge of where the catalogue, the cache and the queues typically give way under load. Talk to our team if you would like to set up load testing and an emergency plan for the coming peak season in a predictable way - the preparation window closes in September.