--- title: "Black Friday Website Checklist for Late Starters | Evaluat" description: "A last-minute Black Friday website checklist with ten performance and reliability checks that still fit in the final weeks, and the changes to leave alone." url: "https://www.evaluat.xyz/blog/black-friday-performance-checklist" last_modified: "2026-11-06" --- [Blog](https://www.evaluat.xyz/blog) [Ecommerce Performance](https://www.evaluat.xyz/blog/category/ecommerce-performance) # The last-minute Black Friday performance checklist Black Friday 2026 is on 27 November, 23 days after this post. If you have not prepared, that is too little time to rebuild anything and enough to find what would break. These ten checks still fit. Most of them only look at your site, and the few that change it should land before your code freeze. Written by: [Ahmad Farzan](https://www.evaluat.xyz/authors/ahmad-farzan) · 4 November 2026 · Updated 6 November 2026 [Beginner's guide](https://www.evaluat.xyz/blog/beginners-guide) Part 19Ecommerce and peak season ![A timeline from 4 November to Black Friday on 27 November 2026, split into two windows. From 4 to 13 November, about eight working days, small changes can still land. From the freeze on 13 November to Black Friday, two weeks are for checks that only look and for watching. Enough time to check, not enough to rebuild.](https://www.evaluat.xyz/blog/black-friday-performance-checklist-cover.svg) Summary If Black Friday is three weeks away and you have not prepared, there is still time to check, but not to rebuild. If your freeze starts two weeks before the day, the working days before it are for small changes and the two weeks after it are for watching. So favour checks that only look. First, write down your peak number and run one load test on the checkout journey, because that test tells you whether you have a problem and how big it is. Fix only what it finds. Before the freeze, list every service you depend on and what you will do if each one fails, tell your payment provider and your host about your peak, check that certificates and domains will not expire over the weekend, and make sure your cache will not be flushed or split by campaign links. In the last fortnight, send your sale emails in batches so you do not create your own spike, rehearse the switches that turn off non-essential features, and write down who does what on the day. Just as important is what not to do. Do not move hosting, DNS or CDN providers now, and do not add new tags or features. Late changes cause outages as often as late traffic does. Listen to this article · 1:14 [Download the audio summary (MP3)](https://www.evaluat.xyz/blog/audio/black-friday-performance-checklist.mp3) Key takeaways - Three weeks out there is time to check, not to rebuild; most of these checks change nothing on the live site. - Run one load test on checkout now, so any fix can land before your code freeze. - List every service you depend on, and tell your payment provider and host about your peak. - Check certificates, cache settings and email send pacing; each causes sale-day trouble that costs little to prevent. - Do not move providers, add tags or switch on new rules this close to the day. ## How much can you still do three weeks before Black Friday? Enough to check, not enough to rebuild. Black Friday 2026 falls on Friday 27 November. If your code freeze starts two weeks before the day, as [part 11 of this guide](https://www.evaluat.xyz/blog/black-friday-code-freeze) suggests, the working days before it are for small changes and the two weeks after it are for watching. So favour checks that only look, and keep every change small and reversible. The busy season may also start before the day itself. Adobe’s 2026 forecast put online discounts at [up to 14% in early November](https://news.adobe.com/news/downloads/pdfs/2026/09/adi-holiday-forecast-release-9-28.pdf), rising to 21% just before Thanksgiving, and US online spending at $12.9 billion on Black Friday. Your traffic may climb through November rather than arrive in one morning. Late changes are a risk of their own. When Microsoft’s Azure Front Door failed for more than eight hours from 29 October 2025, its review traced the trigger to customer configuration changes that exposed a hidden software fault, and to stop further damage the service [automatically blocked all new and in-flight configuration changes from being deployed worldwide](https://azure.status.microsoft/en-us/status/history/?trackingId=YKYN-BWZ). A change you make three weeks out has less time to prove itself than one made in September. If you are earlier than this, the [12-week plan in part 1](https://www.evaluat.xyz/blog/black-friday-readiness-timeline) is the better guide. This list is for everyone else. | # | Check | Looks or changes | Do it by | | -- | ------------------------------------------------------ | ------------------- | ------------------------ | | 1 | Write down your peak number | Looks | This week | | 2 | Load test the checkout journey once | Looks | This week | | 3 | Fix only what the test found, then freeze | Changes | Two weeks before the day | | 4 | List your dependencies and what you do when each fails | Looks | Two weeks before the day | | 5 | Tell your payment provider and your host | Looks | Now | | 6 | Check certificates, domains and DNS | Looks, small change | Two weeks before the day | | 7 | Protect your cache | Looks, small change | Two weeks before the day | | 8 | Pace your own emails | Looks | Before your sends | | 9 | Rehearse the switches you already have | Looks | A week before the day | | 10 | Write down who does what on the day | Looks | A week before the day | ## What should you check this week? Your peak number and your ceiling. Write down how many shoppers you expect at the busiest moment, then run one load test of the checkout journey at that level and above it. The test tells you whether you have a problem, how big it is, and whether there is time to fix it before the freeze. ### 1. Write down your peak number Pull last November’s busiest hour from your analytics, find the busiest minutes inside it, and scale for this year’s growth and offers. [Part 9 of this guide](https://www.evaluat.xyz/blog/sizing-black-friday-load-test) walks through it in an afternoon. The output is one number: shoppers on the site at once at your peak, with a fifth or so added as headroom. The scale of the day is easy to underestimate. Across Shopify’s merchants in 2025, sales [reached a record $5.1 million per minute](https://www.shopify.com/investors/press-releases/shopify-merchants-achieve-record-breaking-14-6-billion-in-black-friday-cyber-monday-sales) at 12:01pm Eastern time on Black Friday. ### 2. Load test the checkout journey once Test the money path: search or category, product page, basket and checkout up to payment. A homepage test measures your CDN, not your shop. Run at your peak number, then above it, and note where response times start to climb. Three rules keep a late test safe. Agree it with your host first. Do not send the load to your payment provider’s test mode. Stripe’s documentation says [we generally discourage this practice because API limits are lower in a sandbox](https://docs.stripe.com/rate-limits), and recommends mocking the payment call with realistic delays instead. And run it before early promotions bring real crowds. If the ceiling is below your peak and there is no time to raise it, the measurement still has a use: it is the admission rate for a [virtual waiting room](https://www.evaluat.xyz/blog/product-drop-queues-waiting-rooms). ### 3. Fix only what the test found, then freeze Fix the one or two problems the test exposed, in revenue order, and re-run the same test to prove the fix. Then freeze code, configuration and tag-manager tags together, because [third-party tags](https://www.evaluat.xyz/blog/third-party-scripts-performance) added after your last test have never met your peak. ## What should you check before your code freeze? The things outside your own code that can still take you down: the providers you depend on, the limits they set, the certificates and domains that can quietly expire, and the cache that keeps your servers from doing every request themselves. Most of these checks are reading and phone calls, not changes. ### 4. List your dependencies and what you do when each fails Write down every outside service a shopper’s journey touches: hosting and cloud, CDN, DNS, payments, search, tax, email, the platform’s own login. Then, for each one, what happens if it fails and what you would do. Autumn 2025 showed why. AWS’s outage in one of its US regions [started at 11:48 PM PDT on October 19 and ended at 2:20 PM PDT on October 20](https://aws.amazon.com/message/101925/), and was traced to [a latent race condition in the DynamoDB DNS management system](https://aws.amazon.com/message/101925/). On Cyber Monday, Shopify merchants had trouble logging in, and TechCrunch reported the problem was in [its login authentication flow, which explains the POS login complications](https://techcrunch.com/2025/12/01/shopify-resolves-outage-disrupting-merchants-on-cyber-monday) in shops. Your plan cannot stop either. It can decide in advance what you do, and how you tell customers. ### 5. Tell your payment provider and your host Payment providers set rate limits. Stripe’s default in live mode is 100 requests per second across an account, and its documentation warns that [a sudden increase in charge volume, such as a flash sale, might result in rate limiting](https://docs.stripe.com/rate-limits). If you expect to hit the limits, contact support, and for a large increase do so [at least 6 weeks in advance](https://docs.stripe.com/rate-limits). Three weeks out, that means asking now and planning to live within today’s limits. Shopify’s flash-sale guide gives the same advice to [contact your payment provider to ensure they can support the volume of sales you expect](https://help.shopify.com/manual/sell-online/frenzy), and suggests a second payment provider as a fallback. Hosts work the same way: Adobe Commerce Cloud asks for surge capacity tickets [at least 48 business hours in advance](https://experienceleague.adobe.com/en/docs/support-resources/adobe-support-tools-guide/adobe-commerce-support/holiday-surge-capacity-requests-for-magento-commerce-cloud), and warns that over Black Friday and Cyber Monday [capacity during this period is limited](https://experienceleague.adobe.com/en/docs/support-resources/adobe-support-tools-guide/adobe-commerce-support/holiday-surge-capacity-requests-for-magento-commerce-cloud). ### 6. Check certificates, domains and DNS Check the expiry date of the security certificate on every hostname a shopper touches: shop, checkout, images, APIs and webhooks. Renewals now come round more often. As GlobalSign explains, the industry’s phased approach [reduced lifespans from 398 days to 200 days on March 15, 2026](https://www.globalsign.com/en/blog/47-day-tls-certificate-lifespan-what-it-means-for-security-teams) for public certificates, and Let’s Encrypt’s expiry reminder emails stopped: [this service ended on June 4, 2025](https://letsencrypt.org/2025/06/26/expiration-notification-service-has-ended). A 200-day certificate issued in mid-May runs out around Black Friday itself. Check domain renewals too. For DNS, leave providers alone, but know your record lifetimes (TTLs). Amazon’s Route 53 guidance is that for records you might switch in a failover, [setting a TTL of 60 or 120 seconds is a common choice](https://docs.aws.amazon.com/Route53/latest/DeveloperGuide/best-practices-dns.html). Lower them only on records you have a real plan to repoint. ### 7. Protect your cache Make sure nothing flushes the whole cache on the day, and that campaign links do not split it. Adobe’s Commerce documentation warns that [clearing cache types during peak demand can increase load on the Admin and cause the site to go down until the operation completes](https://experienceleague.adobe.com/en/docs/commerce-admin/systems/tools/cache-management). Its holiday guide adds that each unique tracking string in a URL [creates a separate cache entry for what’s otherwise the same page, which lowers your cache hit ratio](https://experienceleague.adobe.com/en/docs/support-resources/adobe-support-tools-guide/adobe-commerce-support/adobe-commerce-holiday-readiness/performance-optimization). Open your promotion landing pages with campaign links and check they are served from cache. [Part 16](https://www.evaluat.xyz/blog/caching-explained) explains which caches matter. ## What should you check in the final fortnight? How you behave on the day. Your own emails can create the spike, your fallback switches only help if someone has flipped them before, and an incident goes better when everyone already knows their role. None of these checks changes code, so they fit inside the freeze. ### 8. Pace your own emails A sale email sent to every subscriber at the same minute is a spike you created yourself. Many email tools can send in batches instead. Klaviyo’s gradual send delivers [to a percentage of your recipients at a time](https://help.klaviyo.com/hc/en-us/articles/360050216012), which it describes as [useful for avoiding a spike in website traffic as recipients click through](https://help.klaviyo.com/hc/en-us/articles/360050216012). Schedule the sends for when your team is watching. ### 9. Rehearse the switches you already have Most shops have features they could turn off to protect checkout: recommendations, pop-ups, live chat, heavy tags. Pete Hodgson describes these as [long-lived “Kill Switches” which allow operators of production environments to gracefully degrade non-vital system functionality](https://martinfowler.com/articles/feature-toggles.html) under unusually high load. Shopify’s flash-sale guide lists recommended products and pop-ups among the settings to turn off. Flip each switch once on a quiet day and confirm it works. Building new switches now is new code, so only rehearse the ones you have. ### 10. Write down who does what on the day Google’s SRE book puts preparation first: [develop and document your incident management procedures in advance](https://sre.google/sre-book/managing-incidents/). Name who watches the dashboards, who decides to flip a switch, who talks to customers, and who holds the logins and support numbers for each provider on your list. Keep it to one page, and make sure your status page does not run on the same systems as your shop. ## What should you not do three weeks before Black Friday? Do not make changes that cannot prove themselves before the day. Moving hosting, DNS or CDN providers, launching features, adding tags, and switching on new security rules all carry more risk now than the problem they solve. Leave them until your peak season is over, when a mistake costs a normal day rather than one of the biggest. - **Do not migrate.** A new provider has never served your peak. - **Do not add tags or features.** Each one is an untested change on the busiest pages. - **Do not switch on aggressive bot rules at the last minute.** New rules can block real buyers along with the bots. - **Do not load test the payment provider’s test mode.** Mock the payment step instead. - **Do not flush caches during trading.** Warm them gently, before the emails go. - **Do not trust autoscaling alone.** New servers take minutes to start; pre-scale the night before. ## How Evaluat fits into the last three weeks Evaluat runs each virtual user in its own real browser, so one test this week can walk your checkout journey the way shoppers do, with every image, script and tag loading. The report shows response times and errors per URL, p95 and p99 percentiles, and Core Web Vitals, so you can see which step slows first and at what level. When something fails, the evidence is per shopper. Every session keeps its video, network log and console log, so you can open the session where checkout timed out and see which request took the time. Build a scenario once. Use it everywhere: the same scenario re-runs after each fix, and once more on the frozen build. The boundaries are worth stating. A load test finds the limit of your site, not of your payment provider or your CDN, which is why checks 4 and 5 are separate. Virtual users ramp up over minutes, so a test rehearses a rising peak rather than everyone arriving in the same second. And one test three weeks out is a measurement, not a guarantee; what you do with the result is what counts. Three weeks is enough to know where your site will break and to decide what you will do about it. Measure first, change little, and write the plan down. Test in real browsers. Debug in real sessions. [Book a demo](https://www.evaluat.xyz/demo?intent=performance) to test your checkout before your next peak. [Previous · Part 18Third-party scripts and tag managers: the slowdown you did not write](https://www.evaluat.xyz/blog/third-party-scripts-performance) [Next partNew parts every Wednesday and Thursday. See the guide index.](https://www.evaluat.xyz/blog/beginners-guide) ![Ahmad Farzan, Founder at Evaluat](https://www.evaluat.xyz/authors/ahmad-farzan.jpg) About the author [Ahmad Farzan](https://www.evaluat.xyz/authors/ahmad-farzan) · Founder at Evaluat Founder of Evaluat. Has spent years building and load-testing Adobe Commerce and Magento storefronts, and built Evaluat to test sites the way real browsers actually hit them. [Ahmad Farzan on LinkedIn](https://www.linkedin.com/in/ahmadfarzan/) [Ahmad Farzan on GitHub](https://github.com/farzanahmad) [More from Ahmad](https://www.evaluat.xyz/authors/ahmad-farzan) Common questions ## FAQ ### Is it too late to prepare my website for Black Friday? Not three weeks out, but the work changes. There is time to measure your peak, run a load test, fix the worst problem it finds and check your dependencies. There is not time to migrate platforms or rebuild slow pages safely. ### Is it safe to load test three weeks before Black Friday? Yes, if you plan it. Agree it with your host, test the checkout journey with the payment step mocked rather than sent to your provider's test mode, and run it before early promotions bring real crowds. Run it early enough that a fix can land before your freeze. ### Should I change anything on my site this close to Black Friday? Only small, reversible changes that fix a measured problem, and only before your freeze. Late changes cause outages too. Moving hosting, DNS or CDN providers, adding new features or tags, and switching on new security rules are all safer after the peak. ### How do I stop my website slowing down on Black Friday? Find out where it slows first with a load test of the checkout journey, then fix that or plan around it. Keep your cache from being flushed or split, pace your email sends, and have switches ready to turn off non-essential features such as recommendations and pop-ups if the site starts to labour. ### Do I need to tell my payment provider about Black Friday? If your peak is well above normal, yes. Payment providers set rate limits, and Stripe, for example, asks merchants who expect to exceed them to contact support, with at least six weeks' notice for a large increase. At minimum, know your limits and your provider's support route on the day. ### What causes a Black Friday website crash? Usually one part of the site running out of capacity first, often the database, the checkout or a third-party service such as payments, rather than the whole site at once. Late changes, expired certificates and outages at cloud or CDN providers cause sale-day failures too. ### What should I do if my CDN or cloud provider goes down on Black Friday? Follow the plan you wrote in advance, because there is little you can change during the outage itself. Know which provider each part of your site depends on, what fails over automatically, what you would switch manually, and how you will tell customers. Watch the provider's status page rather than guessing. Related reading ## More from the blog [![A twelve-week countdown to Black Friday. Targets are set at week 12, the first load test runs by week 8, fixes and a re-test by week 6, a spike rehearsal by week 4 and a code freeze from week 2, while the expected traffic curve climbs to its peak on the day.](https://www.evaluat.xyz/blog/black-friday-readiness-timeline-cover.svg)](https://www.evaluat.xyz/blog/black-friday-readiness-timeline) ### [How to prepare your website for Black Friday: the 12-week plan](https://www.evaluat.xyz/blog/black-friday-readiness-timeline) [Most sites that fail on Black Friday morning failed weeks earlier, when nobody rehearsed the traffic. This plan counts down from the day. Set targets from last year's analytics, find your real ceiling while fixes are still possible, rehearse the opening spike, then freeze and stand watch. Starting late? Jump in at your week.](https://www.evaluat.xyz/blog/black-friday-readiness-timeline) [Ahmad Farzan · 2 September 2026](https://www.evaluat.xyz/blog/black-friday-readiness-timeline) [![A worked example of sizing a Black Friday load test from last year's analytics. The busiest hour averaged 600 people on the site at once. Multiplying by 2.4 for the peak minutes after the email send gives 1,440, adding 8% growth gives 1,555, and adding 20% headroom gives a load test target of 1,900 virtual users.](https://www.evaluat.xyz/blog/sizing-black-friday-load-test-cover.svg)](https://www.evaluat.xyz/blog/sizing-black-friday-load-test) ### [How to estimate peak traffic from your analytics](https://www.evaluat.xyz/blog/sizing-black-friday-load-test) [Across the 138 retailers Queue-it tracked, Black Friday 2025 drew 78% more visits than an average October Friday. Your load test needs your own number, and last November's analytics already hold it. Find the busiest hour, find the minutes inside it, scale for growth, and turn the result into virtual users and journeys.](https://www.evaluat.xyz/blog/sizing-black-friday-load-test) [Ahmad Farzan · 3 October 2026](https://www.evaluat.xyz/blog/sizing-black-friday-load-test) [![A code freeze calendar for Black Friday 2026 drawn as a timeline from 26 October to 4 December. A feature freeze starts on Friday 30 October, a full freeze starts on Friday 13 November followed by a final load test on the frozen build, Black Friday falls on Friday 27 November within the peak week, and a gradual thaw begins on Tuesday 1 December.](https://www.evaluat.xyz/blog/black-friday-code-freeze-cover.svg)](https://www.evaluat.xyz/blog/black-friday-code-freeze) ### [What is a code freeze, and should you have one before peak?](https://www.evaluat.xyz/blog/black-friday-code-freeze) [A code freeze does not protect you from the release you shipped in September. It protects the site you last load tested, by stopping changes nobody has proved since. Freeze about two weeks before Black Friday, include tags, configuration and content as well as code, and keep a tested route open for genuine fixes.](https://www.evaluat.xyz/blog/black-friday-code-freeze) [Ahmad Farzan · 7 October 2026](https://www.evaluat.xyz/blog/black-friday-code-freeze) See it on your site Test in real browsers.\ Debug in real sessions. ## Want to see this measured on your app? 30 minutes. We build a scenario on your real customer journey, run a small test, and walk you through the report. [Book a demo](https://www.evaluat.xyz/demo?intent=performance) [How it works](https://www.evaluat.xyz/how-it-works)