Black Friday: an engineering checklist for your platform

Black Friday 2026 falls on Friday 27 November, with Cyber Monday on Monday 30 November. That is sixteen weeks from today, and it is the only piece of good news in this article, because most of what decides whether a platform survives a peak cannot be done in November. This is not a list of promotion ideas. It is an engineering schedule: what to measure in September, what to rebuild in October, what to freeze in November and what not to touch in the final week. The mechanics of how a platform breaks under load we covered separately in the piece on what breaks at 10x traffic. This one is about sequence and dates.

The peak is not a day, it is a handful of minutes across several days

Before you build a schedule, be precise about what you are preparing for. The 2025 numbers say two things at once: the peak spreads across several days, yet inside each of them sits a short window that decides everything.

• The record day is not necessarily Friday. According to Adobe Analytics, US shoppers spent $11.8 billion online on Black Friday 2025 and $14.25 billion on Cyber Monday, the highest single day that market has ever recorded (Adobe release, 2 December 2025).
• The peak inside the peak is measured in minutes. Adobe reports $16 million spent per minute between 8pm and 10pm on Cyber Monday, while Shopify recorded a high of $5.1 million in sales per minute at 12:01pm EST on Black Friday (Shopify release, 2 December 2025).
• The whole window is long. Adobe puts Cyber Week 2025, the stretch from Thanksgiving through Cyber Monday, at $44.2 billion online, up 7.7% year on year. Your freeze window has to cover all of it, not just Friday.

What this means for capacity planning: a daily average is useless. The reference point is your busiest minute, because that is what drains the connection pool and fills the thread queue. And what it means for the calendar is just as concrete: if the record can land on Monday, the change freeze cannot end on Saturday morning when the team exhales after Friday.

One more signal worth reading from the Adobe data: in 2025 Black Friday grew faster than Cyber Monday, 9.1% against 7.1% year on year. Which of the two days wins varies by year and by market, so the technical plan has to cover both rather than bet on one.

The schedule: what to do and when

The table below is the skeleton of this article. The "what you do not do" column matters as much as the other one, because most peak-day failures start with a change made too late, not with a shortage of capacity.

A schedule built around Black Friday on 27 November 2026. The dates are deliberately specific: every week of delay removes options rather than adding them.

One caveat up front: this checklist assumes you control your infrastructure and your code. On a closed SaaS platform some of these items are out of reach, and your job becomes a different one: getting it in writing what the vendor guarantees during peak, what its API limits are, and when it declares its own change freeze.

September: measure first, then do anything else

September has one purpose, which is to turn assumptions into numbers. Without them every October decision is a lottery, because you cannot tell whether the bottleneck is the database, the warehouse integration or the frontend. Three things to get done: a load test, a set of baselines and an inventory of limits.

A load test that is meant to break something

A load test is not there to confirm that everything is fine. It is there to find the layer that gives out first and the number at which it happens. Run it on an environment close to production, against a real catalogue, along the full path through to order placement and a test-mode payment. The bottleneck almost never sits on the homepage.

Our rule of thumb (a recommendation, not an industry standard): aim for at least twice your busiest minute from last year. If you have no data from last year, use ten times your ordinary peak hour. The point is not a flattering result, it is seeing the first error and recording the load at which it appeared.

Write the outcome down as numbers, not impressions. "At 420 orders per minute checkout response time doubles, at 610 the database connection pool runs dry" is the sentence that will pay for every decision you make in October. "It should hold" buys you nothing.

Baselines, or what healthy looks like for you

In its guidance on planned events (the archived December 2018 whitepaper "Infrastructure Event Readiness"), AWS recommends documenting back-to-healthy values for key metrics before the event begins. That sounds trivial until 1am, when you are staring at a chart and cannot tell whether 900 ms is an incident or just a normal evening in your store.

The same document makes a point about proportionality: a tenfold increase in transactions through a load balancer may require a twentyfold increase in storage capacity or database read and write operations. Layers do not scale linearly or evenly, so capacity is planned per layer rather than with a single multiplier for the whole stack.

Limits: the ones you own and the ones you inherit

The most humiliating peak-day failures are rarely about raw capacity. They are about limits nobody remembered. Make the list in September, because some limits are only raised on request, and requests come with deadlines.

• Cloud and hosting quotas: instance counts, bandwidth, database connections, serverless concurrency, per-region account limits. Check which ones lift automatically and which need a ticket.
• Integration API limits: payment gateway, ERP, carriers, marketplaces, email platform. Ask directly about requests per second and about what happens the moment you exceed them.
• Plan and licence ceilings: search, CDN, monitoring and analytics tools are often billed by volume, and hitting the ceiling throttles the service at the worst possible moment.
• Vendor lead times: Google Cloud accepts a peak event request (a service available under Premium Support) at least 30 days before the event, and AWS advises starting Countdown Premium 2 to 3 weeks before a critical event.

Turn those lead times into dates and put them in the calendar today. For 27 November 2026 that means 28 October as the last moment under the 30-day rule, and the first days of November under the 2 to 3 week one. These are not your deadlines, they belong to somebody else, which is why they are not negotiable over the phone in November.

October: the last month you are allowed to touch the architecture

October is for changes that need a deployment and a second round of testing. The rule is simple: if you cannot ship and test it by mid-November, it is not a task for this year, it is a backlog item for January. The four areas below are ordered by how much they usually pay back.

Cache and CDN: taking work off the origin

Cache what looks the same to most visitors: the homepage, category listings, product pages, static assets. Do not cache the basket, contract prices in B2B, or stock levels close to zero. The common mistake is not the absence of caching, it is caching without a thought-through invalidation strategy.

Watch the moment promotions go live. Changing prices across thousands of products invalidates the entire cache in one second, so the first minutes after midnight hit the origin at full force, exactly when traffic is highest. Plan a cache warm-up before the start and check what happens when something forces a mass recalculation.

Queues: separate what must happen now from what can wait

During a peak, only two things truly have to happen immediately: reserving stock and authorising payment. Everything else can wait a second or a minute, including pushing the order to the ERP, updating marketplaces, sending the confirmation email and recalculating recommendations. Every one of those calls made synchronously turns a third-party limit into your own outage.

A queue needs three things to be more than a buffer: retries with increasing back-off, a recorded reason for every failed attempt, and an alert when the queue grows faster than it drains. We break down that exchange, including field mapping and error handling, in the piece on integrating a B2B store with an ERP.

Inventory: overselling during a peak is the rule, not the exception

A promotion concentrates traffic on a dozen products, so hundreds of concurrent orders land on the same database row. If checking and decrementing stock is not one atomic operation, you will sell more units than you hold. At normal traffic that is a rounding error. Over Black Friday weekend it is a daily occurrence and a real cost in refunds.

Three safeguards worth having in place before November: atomic stock reservation inside a transaction, a safety buffer on promoted products, and an automatic sales cut-off below an agreed threshold, instead of support putting out fires by hand.

Observability: dashboard, thresholds and an owner per alert

A peak dashboard does not show everything, only what tells you that you are losing sales. CPU usage is trivia, checkout success rate is a business metric. Give every threshold a named person who receives the alert and has the authority to act, because an alert without an owner is just a notification in a channel.

• Checkout success rate: the share of started orders that end in a payment, measured in windows of ten to fifteen minutes.
• p95 response time separately for listings, product pages and checkout, because an average hides exactly the users who leave.
• Queue depth and the age of the oldest job, the earliest signal that integrations are falling behind.
• 5xx errors and failed payment authorisations broken down by provider, so you can see immediately whose problem it is.
• Database connection pool usage, usually the first counter to hit the ceiling.

While you are there, walk the buying path yourself and count the steps. Under load every redundant field and every extra redirect costs twice, because it multiplies across everyone in the queue. A ten-point checkout audit helps, done in October rather than in the week before the start.

November: freeze, runbook and a way out

November is not when you build resilience, it is when you protect the resilience you already have. Three things cover most of the risk: a change freeze with a clear exception path, a runbook for the day itself, and a rollback plan somebody has actually rehearsed.

Feature freeze: specific dates and an exception path

A freeze only works when it has dates and a decision owner. Here is what we suggest for this year:

• Last feature release: Friday 13 November, with a full regression run and a repeated load test.
• Freeze from Monday 16 November: no more changes to code, theme, integrations or checkout configuration.
• Unfreeze no earlier than Wednesday 2 December: after Cyber Monday, once metrics are back at baseline.
• Hotfix path: one named approver, every fix carries a test and a ready rollback, and every change lands in a log the whole team reads.

This is a recommendation, not an industry standard, and it should be tuned to the team. If you deploy several times a day behind feature flags, with automated tests and a fast rollback, the freeze can be shorter. If releases are manual and happen once a fortnight, it should be longer, because recovery takes longer too.

A runbook for the day

A runbook is an operating manual for the event, not architecture documentation. The AWS material cited earlier lists sections that hold up well in practice, and they make a good skeleton.

• Event details: dates, promotion start times, success criteria, and the people who can make decisions on your side and at each vendor.
• System map: what is in play, the load you expect on each component, and where the single points of failure sit.
• Test results: the numbers from September and October, meaning what breaks at what load.
• Thresholds and procedures: what you do when a metric crosses a line, who signs it off, and what returning to normal looks like.
• Contacts and escalation: phone numbers rather than shared inboxes, plus confirmation that somebody really is on call at the other end.

Rollback, and degrading instead of falling over

AWS recommends that every preparation step has a matching contingency action verified in a test environment, together with an answer to how long a rollback takes and how much data loss is acceptable. A rollback plan nobody has rehearsed is a statement of intent, not a plan.

The second layer is graceful degradation. Rather than letting everything fail, prepare switches that turn off the things people can buy without: search suggestions, recommendations, reviews, counters, heavy third-party widgets. A store that runs stripped down for twenty minutes still sells. A store that does not respond sells nothing.

What not to do in the final week

The last week before the peak, 20 to 26 November, exists so that nothing changes. The list below is not excessive caution, it is a catalogue of things that reliably end in an incident at the most expensive possible moment.

• A platform migration or cutover. Migrations are planned away from the peak and with room to spare, as we described in the piece on migrating without stopping sales. November is the worst possible date.
• A cold start on a new channel. Launching on a new marketplace in Black Friday week doubles the risk: new integrations plus new rules. What that start actually looks like we covered in the piece on the marketplace cold start problem.
• Switching payment gateway or adding a payment method. Even implemented correctly, it changes a path on which you have no historical data.
• A redesign or checkout changes. A/B tests on the basket wait until December. During a peak you cannot separate the effect of the change from the effect of the load.
• A quick database optimisation. Adding an index to a large production table can lock it for minutes. Indexes go in during September, after a test, not on the Wednesday before.
• Silencing alerts because they are noisy. Thresholds come from baselines, not from team fatigue. A silenced alert is an outage your customers discover first.

A separate trap is the idea of showing a maintenance page while you are overloaded. Google Search Central documentation states plainly that 5xx errors prompt Google crawlers to slow down crawling, and that URLs which persistently return a server error are eventually dropped from the index. A few minutes of 503 will not hurt you, but a weekend on an error page is a visibility cost you pay off in the weeks that follow.

Peak day: rhythm, not heroics

A well prepared peak is boring. The team does not improvise, it executes a plan, and every difficult decision was made earlier, calmly. The practice worth borrowing from large launches is a steady rhythm and a single channel.

• An on-call rota with names: who watches the dashboard in each window, who is the backup, and when the handover happens.
• One shared channel: technical and commercial people in the same place, so turning a feature off does not require hunting for the person who can approve it.
• An hourly summary: three sentences on status, the key metrics, any issues and an expected time to fix. Short, regular, and also when things are going well.
• Decisions against thresholds: crossing a line triggers a written procedure rather than a debate about whether this counts as a problem yet.

These days also invert the usual instinct: do not fix what is not broken. A small improvement deployed on Friday afternoon is the largest risk the team can take on that week.

After the peak: the week that sets up next year

Once Cyber Monday is over you are holding the most valuable material of the year: data from real load that no test can reproduce. Run the post mortem within a week, while memories are fresh, and record three things: what broke and at what numbers, what saved the situation, and what the runbook was missing.

If the peak showed that the problem was not one bug but the ceiling of the platform itself, that is a signal to decide rather than to patch again. January is a better month for that than November. How to recognise the moment we set out in the piece on the signs you have outgrown your SaaS platform.

At Seedlight we build eCommerce platforms on the BEAM framework, and we treat peak readiness as continuous work rather than a November scramble: resilience is designed during Engineering, then tests, monitoring and seasonal readiness are looked after in Maintenance and Growth. An honest caveat: no checklist guarantees that nothing will fail. What it gives you is knowing what breaks first, at what number, and what you do about it.