Magento Peak Season Checklist: Get Your Store Ready for Black Friday and Christmas
by Rahul Basu
November 5,2026
Black Friday is on 27 November 2026 and Cyber Monday on 30 November. Between now and then, a Magento store needs four things done: stock that matches the ERP, a cache and cron setup that survives a traffic spike, a load test with real numbers, and a code freeze with a plan for when something breaks anyway.
That leaves about three weeks. Not much time for a replatform. Plenty of time to find the problems that usually show up at 8 p.m. on Black Friday.
The stakes are not small. For 2025, the German retail association HDE forecast €5.8 billion in sales across Black Friday and Cyber Monday alone. It expected €126.2 billion for November and December combined, with €22.2 billion of that online. Those two months make up 18.5% of the retail year. Losing a few hours of checkout in that window is a very different conversation from losing a few hours in February.
This checklist is written for the people who will be on call: developers, shop managers and whoever owns the ERP integration. It assumes Magento Open Source or Adobe Commerce 2.4.x, ideally on a supported version. (If you are not sure, read our Day 1 post on Magento end of support first.)
What usually breaks in peak week?
Big outages are rare. What we see far more often are three smaller failures that pile on top of each other.- Overselling. The shop sells stock that the warehouse doesn't have, because the ERP sync runs every hour and the shop sold 40 units in twenty minutes. You find out when the cancellation emails go out.
- Cache collapse. The full-page cache hit rate drops at exactly the wrong moment. Often the trigger is internal: a large stock or price import from the ERP invalidates thousands of cached pages, and every visitor suddenly hits PHP and the database directly.
- Background jobs falling behind. Cron stalls, indexers lag, order confirmation emails queue up, and orders stop reaching the ERP. The storefront looks fine. Everything behind it is backing up.
Step 1: Make stock match the ERP before the rush
If your shop runs on SAP Business One or another ERP, the ERP is the source of truth for stock. Magento only shows a copy. During peak week, the gap between the two is where overselling happens. Three checks to run now: Clean up reservations. Magento's Multi-Source Inventory (MSI) tracks reservations for placed orders that haven't shipped yet. Cancelled orders or failed imports can leave stale reservations behind, which makes salable quantities wrong. # List orders whose reservations no longer add up bin/magento inventory:reservation:list-inconsistencies -r # Fix them by creating compensating reservations bin/magento inventory:reservation:list-inconsistencies -r | \ bin/magento inventory:reservation:create-compensations Shorten the sync interval, or switch to events. An hourly stock sync is fine in March. In peak week it isn't. Move stock updates to every few minutes, or better, push changes from the ERP when they happen. Order export in the other direction should be close to real time, so the warehouse can pick and the ERP can reserve. Set a safety buffer. Use the Out-of-Stock Threshold (Stores → Configuration → Catalog → Inventory) to hold back a few units on fast movers. Selling 98 of 100 units and shipping all of them beats selling 100 and cancelling three. One warning. A full stock sync of 20,000 SKUs every five minutes will hammer your cache (see Step 2). Sync deltas, meaning only the items that changed, not the whole catalogue. Ask whoever maintains your connector how it handles this. It's one of the first things we look at on an integration before November.Step 2: Check cache, cron and indexers
Know your cache hit rate. With Varnish in front of Magento, most catalogue traffic should never reach PHP. Measure it today so you have a baseline: varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss If hits aren't clearly ahead of misses on category and product pages, find out why before November 27. Common culprits are cookies or query parameters that make every request unique (tracking parameters are a classic), and blocks marked cacheable="false" in a layout file, which switches off the full-page cache for the whole page. Keep sessions and cache apart. Sessions and cache should not share a Redis or Valkey database. When the cache is flushed or evicts keys under memory pressure, you don't want customers losing their carts. In app/etc/env.php: 'session' => [ 'save' => 'redis', 'redis' => [ 'host' => 'valkey-sessions', 'port' => '6379', 'database' => '2', 'max_concurrency' => '20', ], ], Put every indexer on schedule. "Update on Save" reindexes in the same request as the change. Under load, that is a bad idea. bin/magento indexer:set-mode schedule bin/magento indexer:status Move work out of the checkout request. Two settings that help when orders come in fast: # Send order emails from cron instead of during checkout bin/magento config:set sales_email/general/async_sending 1 # Update the admin order grid asynchronously bin/magento config:set dev/grid/async_indexing 1 Watch cron, not just the storefront. A stuck cron job won't take the shop down. It will quietly stop emails, indexing and ERP exports. This query shows what cron did in the last hour: SELECT job_code, status, COUNT(*) AS jobs FROM cron_schedule WHERE scheduled_at > NOW() - INTERVAL 1 HOUR GROUP BY job_code, status ORDER BY job_code; Lots of missed or long-running running entries mean you have a problem to fix now, not in peak week. Load test with real numbers. Take last year's peak hour from your analytics, multiply it by two or three, and test against staging, never production. A short k6 script is enough to start: import http from 'k6/http'; import { check, sleep } from 'k6'; export const options = { stages: [ { duration: '5m', target: 50 }, { duration: '15m', target: 300 }, { duration: '5m', target: 0 }, ], thresholds: { http_req_duration: ['p(95)<1500'], http_req_failed: ['rate<0.01'], }, }; export default function () { const base = __ENV.BASE_URL; const res = http.get(`${base}/`); check(res, { 'status 200': (r) => r.status === 200 }); http.get(`${base}/sale.html`); http.get(`${base}/catalogsearch/result/?q=jacket`); sleep(1); } Browsing traffic is the easy part. Add cart and checkout calls through the REST API, and run an ERP stock sync during the test. That combination is what actually happens on Black Friday.Step 3: Get delivery dates and discount prices right
This part isn't technical, but it ends up in your support inbox if you skip it. Publish delivery cut-offs early. Customers want to know one thing in December: will it arrive before the 24th? Check your carriers' Christmas cut-off dates, add a day of buffer for your own picking, and show the result in three places:- a site-wide banner from early December
- on the product page, next to the delivery estimate
- in the checkout, before the customer pays
- You need price history. Magento doesn't store the lowest price of the last 30 days out of the box. Use an extension or a custom module that records it, and check it's working before you start the campaign.
- Watch the "Special Price" field. If the "old" price shown next to a special price was only valid for a few days in October, the comparison is not compliant. Black Week is a favourite time for warning letters on exactly this point.
Step 4: Freeze the code and plan for failure
Set a freeze date and stick to it. A sensible window for 2026 is Friday 20 November to Monday 4 January. During the freeze, nothing gets deployed except critical security fixes. No new extensions. No "small" theme tweaks. No ERP connector updates. The Adobe patch calendar works in your favour this year. The November security release is due on 10 November (the second Tuesday), and 2.4.9-p1 is also expected this month. Install and test both before the freeze. The next regular slot is 8 December. Only apply it if Adobe rates a fix as critical, and run it through staging first like any other patch. Write the incident plan down. Not in someone's head. One page is enough, as long as it answers these questions:- Who is on call each day from 27 November to 31 December, and how do you reach them?
- Who do you call at the hosting provider, the payment provider and the ERP partner? Have the numbers ready.
- How do you roll back the last deployment, and how long does it take?
- Who decides to switch on maintenance mode, and what does the customer see?
- If orders stop reaching the ERP, how will you export them manually?
The checklist
Print it, share it with the team, tick it off. By 13 November- Magento on a supported version with the November security patch installed
- MSI reservation inconsistencies checked and fixed
- ERP stock sync running on deltas, every few minutes or event-based
- Out-of-stock threshold set for fast-moving products
- All indexers on "Update by Schedule"
- Async email sending and async grid indexing switched on
- Varnish hit rate measured and cache-busting pages fixed
- Sessions and cache on separate Redis/Valkey databases
- Load test passed at 2–3× last year's peak, including checkout and an ERP sync
- 30-day lowest price recorded for every discounted product
- Delivery cut-off banner prepared as a CMS block
- Incident plan written, on-call rota agreed, contacts collected
- Alerts set up for checkout errors, payments, cron and ERP order export
Need a second pair of eyes before 27 November?
Ingold Solutions runs peak-season checks for Magento and Adobe Commerce stores, including the SAP Business One integration. We look at stock sync, caching, cron, hosting and your incident plan, and tell you what to fix before the freeze. As an Adobe Solution Partner, SAP Silver Partner, we cover the shop and the ERP side in one check.
