How to prepare your online store for Black Friday — the technical side

An online store rarely goes down at 11 a.m. on an ordinary Tuesday. It goes down at 8:03 p.m. on a Friday, three minutes after the newsletter with the discount code lands in tens of thousands of inboxes and the Facebook ads hit full spend. The page loads, the cart loads, and then the payment step spins forever. The customer refreshes, pays a second time, or closes the tab and buys from a competitor.

This year Black Friday falls on November 27 and Cyber Monday on November 30. The deals run through the whole of Black Week, though, and many start as early as mid-November. Most guides focus on setting up promotions and campaigns. This one covers the other half of the work: making sure your store can handle the traffic those campaigns bring in.

The figures come from data from Shoper (in Polish) covering more than ten thousand stores, a summary published by BLIK, a Deloitte report commissioned by Google, and Baymard Institute research. The Deloitte study draws on data from 37 brands and shows a correlation; it wasn’t a controlled experiment. Even so, its conclusion matches the rest of the data: at the height of the season, every second of delay and every error costs more than usual. Then there are phones. According to a September 2026 Gemius report, online stores in Poland average 14 million daily users on phones and 3 million on computers (Gemius, in Polish). Your market may look different, but if you only test your store on an office laptop, you’re probably testing the version a minority of your customers use.

Shopify starts preparing six months ahead: in 2025 it ran five scale tests between April and October (Shopify Engineering). A smaller store doesn’t need a program on that scale, but it does need at least one honest test. Four weeks is enough for that.

“The store has to handle a lot of traffic” tells your tech team nothing. They need two numbers: how many people are in the store at the same time, and how many orders per minute come in during the busiest hour.

The simplest way to estimate them:

1. Find last year’s busiest hour in Google Analytics. It’s usually an evening hour on Black Friday or the moment a newsletter went out.
2. Factor in your store’s growth year over year. If sales are up 30%, multiply last year’s peak by 1.3.
3. Add the effect of campaigns you didn’t run last year: a new mailing list, an influencer, a bigger ad budget.
4. Double the result as a safety margin.

It’s not an exact science, but it gives you a target. If you end up with 600 concurrent users and 15 orders per minute, the load test should check 1,200 users and 30 orders per minute, and then answer the question of what breaks first when you push higher still.

Pay attention to the shape of the traffic as well as its height. A newsletter sent to your entire list at once produces a spike within minutes. Plenty of stores cope with a large number of visits spread out over time, then fall over during a five-minute peak. Sometimes the cheapest “performance optimization” is sending the newsletter in three batches, 20 minutes apart.

Start small. The k6 documentation recommends a simple progression: a smoke test first, then gradually heavier load and longer runs. There’s no point unleashing a thousand virtual shoppers before the script runs cleanly for five.

Test the checkout path. Your test script should do what a customer does: land on a category page from an ad, apply a filter, open a product, add it to the cart, log in or check out as a guest, choose delivery, and reach the payment step. The homepage is often cached and will survive anything. The cart and the order always hit the database.

Use an environment that resembles production. A test on a developer’s laptop or the smallest staging server will show you that “it’s slow” without telling you where the limit is in production. If you don’t have a separate environment with the same configuration, test production at night, in an agreed window, and either stop the script just before the actual payment or point it at your payment provider’s test account. Afterwards, clean up the test orders, stock reservations, and any emails the test sent out.

Give your providers a heads-up. Your payment provider, hosting company, or CDN may treat a sudden surge from a handful of IP addresses as an attack. A short email before the test spares you surprises, like traffic getting blocked halfway through the run, and spares everyone’s nerves. On subscription platforms such as Shopify or Shoper, also check the terms of service to see whether, and under what conditions, you’re allowed to load-test.

Watch the right numbers. Average response time lies, because it hides the customers who waited eight seconds. Track the time within which 95% of requests complete (known as p95), the error rate, and which part of the system starts choking first: CPU, database, memory, or the job queue.

Retest after every fix. Removing one bottleneck almost always exposes the next. A four-week plan should allow for at least two full cycles of test, fix, and test again.

Google measures page speed with three Core Web Vitals. Largest Contentful Paint (LCP), the time it takes to display the largest element, should be 2.5 seconds or less. Interaction to Next Paint (INP), the response to an interaction such as a click or tap, should be 200 milliseconds or less. Cumulative Layout Shift (CLS), which measures how much the layout jumps around, should be no more than 0.1. At least 75% of page loads need to meet each threshold, measured separately on mobile and desktop (web.dev). In 2025, only 48% of mobile pages met all three (Web Almanac).

In online stores, third-party scripts are often the culprit. For comparison, the median across all websites, stores or otherwise, is 79 requests to third-party services per mobile page (Web Almanac). Think ad pixels, a tag manager, chat, a review widget, a heatmap, and an A/B testing tool. More get added before the season, because every campaign wants its own tracking.

Audit them before the sale: list every script, note who needs it and why, and switch off the ones nobody will stand up for. For the rest, prepare an “emergency mode,” a way to quickly turn off chat, session recordings, or personalization if the store starts slowing down under load.

The cheapest server is the one a request never reaches. Category pages, product pages, images, scripts, and stylesheets for logged-out customers can be served from cache or a CDN. The cart, checkout, customer account, and anything else tied to a specific person have to go to the store itself.

Check three things before the sale:

• How long pages stay in cache and how the cache gets cleared. If you switch to sale prices at midnight and the cache holds pages for an hour, some customers will see the old prices for that hour. Worse, the cart may calculate a different price from the one on the product page.
• Warming the cache before launch. The first request after a cache purge is the most expensive one. If you clear everything at 8 p.m. and send the newsletter at 8 p.m., the first few thousand requests go straight to the server.
• Stock levels. A sold-out product can’t sit in cache for an hour marked as available. Stock should be read live, or at least checked when an item is added to the cart.

A CDN is also one more component that can fail. On November 18, 2025, ten days before Black Friday, a Cloudflare outage caused errors for several hours on sites that use the service (Cloudflare). Work out in advance whether you can quickly send traffic straight to your server if you have to, and who has the access to do it.

Prices come with one more requirement, a legal one this time. Across the EU, the Omnibus Directive requires a store that announces a price reduction to show the lowest price it charged in the 30 days before the reduction. Member states have applied the rule since 2022 or 2023; in Poland it has been in force since January 1, 2023. UOKiK, Poland’s consumer protection authority, spells out how it works there: the lowest price includes even prices that applied for a single day, and it’s calculated separately for each sales channel (UOKiK, in Polish). In practice, this is a technical requirement. The store has to keep a price history and calculate the figure correctly, including for products whose prices were changed by hand or through an import. Before the sale goes live, spot-check a few products, starting with the ones repriced by import.

Payment is where an error costs the most, because the customer had already made up their mind. Four things to go through with your tech team:

A second payment method ready to switch on. Payment providers have bad days too. On April 2, 2026, PayU, a payment provider widely used in Poland, spent about an hour fending off a DDoS attack, and its payment methods were temporarily unavailable (Wprost, in Polish). Being able to move customers to another provider quickly can save the evening. The setup has to be prepared and tested in advance: nobody opens a new account with a payment provider on a Friday night.

Protection against double charges. When a payment takes a long time to confirm, customers click again. The store should recognize the repeat as the same transaction instead of creating a second order and charging the customer twice. The usual technical tool for this is an idempotency key attached to every payment attempt.

Payment notifications that go through a queue. The payment provider tells your store that an order has been paid in a separate request (a webhook). If the store is overloaded at that moment and doesn’t accept it, the order can get stuck as unpaid even though the money has already left the customer’s account. Accept these notifications immediately, process them from a queue, and every 15 minutes or so check the provider’s API for the status of orders still showing as unpaid.

Limits on external services. Shipping label generation, SMS delivery, and discount systems all have request limits of their own. Check them before the peak.

Many peak-season outages have less to do with the traffic itself than with changes made just before it. Google’s SRE team estimates that roughly 70% of outages are caused by changes to a live system (Google SRE). A new plugin, a “small fix” to the cart, a theme update on Thursday evening. That’s why, about a week before your sale starts, you should announce a change freeze (if you launch on November 16, freeze from November 9). From then on, only fixes for bugs that block sales go to production, and only after sign-off from the person responsible for the store.

The contingency plan doesn’t need to be a long document. One page will do, as long as it covers:

• who is on call from Friday to Monday, nights included, with phone numbers and not just email addresses
• how to roll back the latest deployment, tested for real, because “it should work” doesn’t count
• contacts for your hosting company, payment provider, and the agency running your campaigns, so the ads can be paused if something goes wrong
• what you do when the store can’t keep up, such as switching on a queue page or a temporary-overload message instead of a server error
• a ready-to-post message for customers on your site and social media

If your store runs in the cloud, also check that autoscaling has a sensible upper limit and that someone gets alerted when costs suddenly jump. Unlimited scaling protects you from an outage, but it can also produce a bill nobody expected.

The sale weekend is the best free load test you’ll get all year. Write down the traffic level at which the store started to slow down, which alerts were useful and which were just noise, and what had to be fixed live. Hold on to the test scripts and the contingency plan. You’ll need them again in a few weeks, before the holiday order peak.

If your preparations show that the store needs ongoing infrastructure care, read how DevOps as a Service works: maintenance with on-call coverage and a response when production goes down. You’ll find the scope and rates on our DevOps services page. And if you’re still planning a new store, see how the first version of the Bezuma store was built in three weeks.