OPERATIONS · PERFORMANCE · SHOPIFY PLUS · 21 OCTOBER 2025 · 9 MIN READ
Peak season readiness for a Shopify Plus store
Shopify scales checkout for you. What breaks at peak is everything you added on top of it — and the rehearsal nobody ran.
Not by preparing for traffic. Shopify hosts and scales checkout, and a Plus store that falls over at peak has almost never been beaten by concurrency — it has been beaten by an app that stopped responding, an integration that queued up behind its own backlog, an oversell nobody noticed for six hours, or a change shipped on the day. Readiness is therefore four things: freeze the code early enough that the freeze means something, audit what runs on the page and what runs behind it, decide in advance how you will handle the failures you cannot prevent, and rehearse the decisions rather than the code. If it is late October and you are considering a theme rebuild before Black Friday, the honest advice is not to. Ship nothing structural, and spend the time on the list below instead.
IN SHORT
- Shopify hosts checkout, so raw traffic capacity is not the thing to engineer around; what you added on top of the platform is.
- Freeze code roughly two weeks before peak, not two days — a freeze that starts after the last risky change has shipped is not a freeze.
- Shopify documents bot protection as a Shopify Plus feature, scheduled as an event, limited to 60 minutes and to the Online Store sales channel.
- Every third-party script on the page is a dependency you cannot scale, patch or roll back; peak is when that matters.
- Decide the oversell policy before peak, because the alternative is deciding it at 2am with a queue of angry customers.
- Rehearse the decisions — who declares an incident, who can revert, who talks to customers — not just the technical rollback.
- Most stores would gain more from removing four apps than from any optimisation they could buy in October.
What actually fails, in rough order of frequency
It is worth being specific about the failure modes, because the preparation people instinctively do — load testing the storefront — addresses the one that happens least.
An app stops responding. Not yours, and not Shopify's. A reviews widget, a personalisation service, a stock-notification app: something that injects a script and now has a request in front of your page that is timing out. On a normal Tuesday that is a slow page. At 40× traffic it is every page, and you cannot fix it, because the code is not yours and the vendor is having the same day you are.
An integration falls behind. The ERP sync, the 3PL feed, the warehouse dispatch file. These are usually sized for normal volume and degrade in a way nobody watches: orders are taken fine and simply do not arrive anywhere. The symptom shows up in fulfilment two days later, which is the worst possible time to discover it.
Inventory drifts and you oversell. Peak compresses the window between the sale and the sync, so a lag that is harmless in November is an oversold bestseller on the 28th.
Somebody ships a change. A copy tweak, a discount fix, an "it is only CSS" change. This is the most preventable item on the list and it still happens every year.
Traffic actually exceeds capacity. It happens — usually to something custom you have put in front of Shopify, such as a headless front end, a middleware layer or a bespoke API, rather than to checkout itself.
The freeze, and what it is actually for
A code freeze is not risk theatre. Its purpose is to leave enough time between the last change and peak that a latent problem surfaces under real traffic while someone is still able to fix it. A freeze that begins on the Wednesday before Black Friday gives you nothing, because the change that will break you shipped on Tuesday and nobody has seen it under load yet.
Two weeks is the working rule. Everything structural lands before that: theme changes, app installs, app removals, integration changes, checkout customisations, anything that touches the order path. After the freeze, three categories stay open — content, merchandising and pricing — because those are what the business actually needs to move during peak, and they are the changes that can be reverted by one person in the admin without a deploy.
Write down what is exempt before the freeze starts, and who approves an exception. "We will decide if it comes up" means the exception is granted at the moment everyone is most tired and least able to assess it.
Getting merchandising changes into that safe category is a build decision you make months earlier, not a policy you write in November. A store whose campaign pages are assembled from tested, reusable sections can change its entire Black Friday front page without a developer; a store whose campaign pages are bespoke templates has to choose between shipping during a freeze and not shipping at all.
Audit what runs, and be willing to remove things
The single highest-value week of peak preparation is usually spent deleting. Not optimising — deleting.
List every app, and for each one answer three questions: does it inject a script into the storefront, is anyone measurably using it, and what happens to the site if the vendor has a bad day. Apps that inject scripts are the ones to be ruthless about, because their failure mode is your page. An app that runs purely in the admin or through the API can degrade without a customer ever noticing; a script in the head cannot.
The predictable objection is that removing an app might cost conversions. Sometimes true, and worth testing — in January. What is certain is that every script on the page is a third-party dependency you cannot scale, cannot patch and cannot roll back during the one week where all three matter. Shopify's own theme performance guidance points the same direction: remove render-blocking apps, and load scripts only when a user actually interacts with the component that needs them.
Do the same for the integrations nobody thinks of as apps. For each one: what is its throughput per hour at normal volume, what happens when it exceeds that, does it retry, and does anyone get told. If the answer to the last question is no, fix that first — an integration that fails loudly is a manageable problem, and one that fails quietly is a week of manual reconciliation in December.
- Every storefront script: keep, defer, or remove — decided before the freeze, not during it.
- Every integration: known throughput, defined retry behaviour, and an alert that reaches a human.
- Every scheduled job: does it collide with peak traffic, and can it be moved to a quiet hour.
- Every webhook consumer: what happens to the orders it drops, and how you would replay them.
- Every custom service in front of Shopify: this is the tier that genuinely needs capacity planning.
Drops, bots and the Plus-only lever
If your peak includes a timed drop rather than a general sale, the failure mode changes: the risk is not volume but automation buying your stock in the first ninety seconds and reselling it.
Shopify documents bot protection as a feature available only to merchants on a Shopify Plus plan. It is scheduled as an event rather than left permanently on, and the constraints are worth knowing before you plan around it: an event lasts up to 60 minutes, it applies to the Online Store sales channel only, and it covers either all published products or a specified set of up to 500 items. The challenge itself can be served by reCAPTCHA or hCaptcha, and the separate setting that stops bots auto-completing checkout is documented as active by default.
Read those limits as a design constraint on the drop. A sixty-minute window means the drop needs a start time you commit to in advance, not a vague "sometime Friday". The Online Store scope means a drop run through another channel is not covered. And the 500-item cap means a broad sale is protected as "all published products" or not at all.
Rehearse it once on a quiet day. Bot protection that nobody has seen before is a live experiment on your most important hour.
Decide the unhappy paths in advance
The technical rollback plan is the easy half and most teams have one. The half that gets skipped is the set of business decisions that will be needed under pressure, and these are far harder to make well at 2am.
Oversell. You will oversell something. Decide now: do you cancel and refund with an apology, do you substitute, do you hold and ship late, and at what value does the answer change. Write the customer email now too, while someone can edit it calmly.
A discount behaving wrongly. If a code stacks in a way it should not, is the policy to honour it and fix the rule, or to cancel the orders? Both are defensible; deciding mid-incident is not.
Degrading deliberately. Know in advance which features you would switch off to keep checkout working — recommendations, live stock counts, personalisation, the reviews widget. Being able to name them is most of the work; being able to switch them off without a deploy is the rest.
Who is on. A name and a phone number per shift, someone with production access, someone who can decide, and someone who can talk to customers. If that list does not exist in writing, it does not exist. This is the part clients most often ask us to cover, and it is the part that costs least to arrange in October and most to improvise in November.
What we would talk you out of in October
Three things get proposed every autumn and none of them survives an honest look at the calendar.
A theme rebuild. A better theme is worth building. It is not worth launching six weeks before your highest-revenue week, because the whole value of a rebuild is the problems it surfaces, and you want those surfacing in February.
A new app to fix performance. Adding a script to make the page faster is a plan with an obvious internal contradiction. The measurable win available in October is removing things, not installing them.
A load test of the storefront. Shopify runs checkout, and load-testing someone else's infrastructure tells you about their capacity, not your readiness — it may also breach the terms you agreed to. If you have built custom services in front of Shopify, test those; that is where your capacity risk actually lives.
What is genuinely worth doing in the remaining weeks is unglamorous: freeze early, delete what you can, instrument the integrations, write down the decisions, and know who is awake. Nobody ever regretted the boring version of this list.
Questions this raises
Does Shopify Plus need capacity planning for Black Friday?
Not for checkout — Shopify hosts and scales that. Your capacity planning applies to anything you have put in front of or alongside it: a headless front end, middleware, a custom API, or an integration sized for ordinary volume. Those are yours to test, and they are where peak failures actually originate.
When should a peak code freeze start?
About two weeks before, so that a latent problem surfaces under real traffic while there is still time to fix it. Keep content, merchandising and pricing changes open through the freeze — they are what the business needs to move and they can be reverted in the admin without a deploy.
Is Shopify bot protection enough for a limited drop?
It helps, within documented limits: Shopify lists it as a Plus-only feature, scheduled as an event of up to 60 minutes, applying to the Online Store sales channel and to either all published products or up to 500 specified items. Plan the drop around those constraints — a fixed start time, the right channel — and rehearse it once before the day.
Should we remove apps before peak?
Remove the ones that inject scripts into the storefront and that nobody can show is earning its place. Each is a third-party dependency you cannot scale, patch or roll back during the week when all three matter. Test whether the removal costs conversions in January, not in November.
What breaks most often during peak on Shopify?
In our experience, in order: a third-party script that stops responding, an integration that silently falls behind, inventory drift causing oversells, and somebody shipping a change during what was supposed to be a freeze. Genuine traffic overload is the least common, and when it happens it is usually a custom service rather than Shopify.
Can we still launch a new theme before Black Friday?
You can, and we would advise against it. The value of a rebuild is the problems it exposes, and you want them exposed in a quiet month. If the current theme is genuinely unusable, fix the specific pages that lose money and launch the rest afterwards.
NEXT STEP
Free store audit
A senior Shopify engineer reviews your storefront, theme performance and checkout, then sends a prioritised list of fixes.