Black Friday Capacity Planning Before the Change Freeze

Somewhere in the next two weeks, your team will freeze changes for the holiday peak. After that, the only changes are emergencies. Anything you want in place on Black Friday has to be measured, tested and done before the freeze starts.

This is the order to work in: set the dates, find last year's peak, load test until something breaks, add headroom in the right places, make failure survivable, and make sure someone will see the alert at 3 a.m. If your architecture still has single points of failure, start with our overview of high availability options, and the glossary entry on the load balancer if that term is new.

Set the freeze date and work backwards

This year, Thanksgiving is Thursday 26 November, Black Friday is 27 November and Cyber Monday is 30 November. Many teams freeze one to two weeks before Black Friday, so for most of you the working window is the first half of November.

Decide three things now:

The freeze start date, written on a calendar the whole team can see
Who can approve an exception, and how they are reached at the weekend
What counts as an emergency, so that "small" changes do not slip through

Then put the checks below into the days before that date.

Check 1: Know last year's peak and this year's target

Pull the numbers from last year's peak day: requests per second, concurrent sessions, orders per minute, database connections and CPU on your busiest servers. Note the hour they peaked, not just the day.

Then talk to marketing. Traffic follows the email send and the ad launch more than the calendar. If the big email goes out at 6 a.m. Eastern, your peak starts at 6:01. Agree this year's send times and expected volume, and plan for a peak above last year's.

Check 2: Find the bottleneck before customers do

Build a copy of production for testing and load test it. Ramp past this year's target until something breaks, so you know where the ceiling is rather than guessing.

Watch where it breaks. It is rarely the web servers. The usual suspects are:

Database connections, which run out before CPU does
Checkout, where every order calls the payment gateway, tax and shipping services
Session storage, if sessions live on individual web servers
Uncached pages, especially search and filtered category pages
Third-party scripts and APIs, which you cannot scale at all
Disk performance on the database volume

Request path for an online store showing that the database, payment gateway and uncached search are more likely bottlenecks during a traffic peak than the web servers. — Follow the whole checkout journey: the limiting component may be the database, an integration or uncached search.

If you want engineers to run this review with you, InMotion Cloud engineers can look at your capacity plan as part of the managed services included on every plan.

Check 3: Add headroom where it matters

Add capacity to the component that broke first in testing, not to everything. If the database ran out of connections, more web servers will make it worse.

Size up or add servers before the freeze. Resizing usually needs a restart, and new servers need warming up. Neither belongs on peak day.

Protect the database. Use connection pooling, add read replicas for read-heavy pages, and add indexes for the queries that slowed down under load.

Cache what you can. Product pages, category pages and images rarely change during the sale. Every cached request is one your servers do not handle.

Leave a margin. Plan for a peak above your load test target, because the real peak never matches the forecast exactly.

Check 4: Make failure survivable

Something will fail. The question is whether a customer notices.

Run at least two of everything in the request path, behind a load balancer with health checks that remove a failed server automatically.
Spread them across physical hosts with anti-affinity rules, so one host failure cannot take out both copies.
Decide what to switch off under load. Recommendations, live stock counts and review widgets can go dark so that checkout keeps working.
Queue anything that can wait. Confirmation emails and stock sync can run a few minutes behind without anyone minding.

Bar showing normal traffic, last year's peak, this year's target and headroom, with the load test breaking point placed well beyond the expected peak. — Leave tested headroom between the expected peak and the point where the system breaks.

Check 5: Monitoring you would trust at 3 a.m.

A dashboard nobody watches does not count. Before the freeze:

Alert on what customers feel: checkout errors, page response times and failed payments, not just CPU.
Test every alert by triggering it on purpose and checking that it reaches a person.
Publish the on-call rota for the whole peak weekend, with a backup for each shift.
Keep a contact list for your host, CDN, payment gateway and any critical third party.

Plan for hostile traffic too. Peak days attract attacks, and on metered cloud, DDoS traffic can turn into a bill as well as an outage.

Check 6: Backups, rollback and the runbook

Test a restore before the freeze. Peak weekend is the worst time to find out a backup does not work.

Take a snapshot immediately before the last change goes in, so you can roll back quickly.

Write the runbook for the four things you are most likely to do under pressure: add capacity, fail over, block abusive traffic and roll back a change. Include who is allowed to do each one.

What not to do during the freeze

No major version upgrades of your platform, database or plugins
No new features, however small
No DNS, CDN or payment provider migrations
No new third-party scripts on product or checkout pages

November timeline showing measuring, load testing and fixing before the change freeze, the peak from 27 to 30 November, and a review in early December. — Finish testing and fixes before the freeze, protect the November 27–30 peak, and review the results in December.

How InMotion Cloud helps with peak season

InMotion Cloud plans have one fixed monthly price covering compute, storage and data transfer, so a traffic peak does not arrive later as a surprise bill. You can resize virtual machines or add new ones within your plan's resources, and put them behind load balancers with health checks. DDoS filtering is included on every plan, and requests go straight to senior engineers who know your environment.

Going over your plan's resource allowance during a peak does not stop or throttle your environment. If it keeps happening, we will talk to you about a larger plan.

What we cannot do is load test your application for you, raise your payment gateway's rate limits, or fix a slow query we have not seen. The earlier you start the checks above, the more we can help.

Summary

Set the freeze date, find last year's peak and agree this year's target with marketing. Load test until something breaks, fix that first, and add headroom where it counts. Make failure survivable, make alerts reach a person, and test a restore. Then leave everything alone until December.

Not sure your stack will hold on Black Friday?

InMotion Cloud engineers will review your capacity plan with you before the freeze.

Talk to a cloud architect

Frequently asked questions

When should a Black Friday change freeze start? Many teams freeze one to two weeks before Black Friday. Earlier is safer, as long as your load testing and fixes are finished first.

How much headroom should I plan for? Enough that your load test breaking point sits well above this year's expected peak. Base the target on last year's numbers and this year's marketing plan.

Should I load test production? Test a copy of production where you can. If you must test production, do it at a quiet time, warn your providers, and stop at a safe level.

What if we hit a limit during the freeze? Follow your runbook. Adding capacity or blocking abusive traffic are usually allowed as emergency changes. New features and upgrades are not.

Will adding more servers fix a slow site? Only if the web tier is the bottleneck. Most peak-day slowdowns come from the database, checkout integrations or uncached pages.