{"id":4017,"date":"2026-11-05T08:19:34","date_gmt":"2026-11-05T08:19:34","guid":{"rendered":"https:\/\/www.magento2-agentur.de\/?p=4017"},"modified":"2026-11-05T08:19:34","modified_gmt":"2026-11-05T08:19:34","slug":"magento-peak-season-checklist-get-your-store-ready-for-black-friday-and-christmas","status":"publish","type":"post","link":"https:\/\/www.magento2-agentur.de\/en\/magento-peak-season-checklist-get-your-store-ready-for-black-friday-and-christmas\/","title":{"rendered":"Magento Peak Season Checklist: Get Your Store Ready for Black Friday and Christmas"},"content":{"rendered":"

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.<\/span>\u00a0<\/span><\/p>\n

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.<\/span>\u00a0<\/span><\/p>\n

The stakes are not small. For 2025, the German retail association HDE forecast \u20ac5.8 billion in sales across Black Friday and Cyber Monday alone. It expected \u20ac126.2 billion for November and December combined, with \u20ac22.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.<\/span>\u00a0<\/span><\/p>\n

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.)<\/span>\u00a0<\/span><\/p>\n

<\/b>What usually breaks in peak week?<\/span><\/b>\u00a0<\/span><\/h2>\n

Big outages are rare. What we see far more often are three smaller failures that pile on top of each other.<\/span>\u00a0<\/span><\/p>\n

    \n
  • Overselling.<\/span><\/b> 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
      \n
    • Cache collapse.<\/span><\/b> 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
        \n
      • Background jobs falling behind.<\/span><\/b> 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

        Notice that only one of these is about raw server capacity. Most peak-week problems are about how the shop and the systems around it behave under load. So that is where the checklist starts.<\/span>\u00a0<\/span><\/p>\n

        <\/b>Step 1: Make stock match the ERP before the rush<\/span><\/b>\u00a0<\/span><\/h3>\n

        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.<\/span>\u00a0<\/span><\/p>\n

        Three checks to run now:<\/span>\u00a0<\/span><\/p>\n

        Clean up reservations.<\/span><\/b> 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.<\/span>\u00a0<\/span><\/p>\n

        # List orders whose reservations no longer add up<\/span>
        \nbin\/magento inventory:reservation:list-inconsistencies -r<\/span><\/p>\n

        # Fix them by creating compensating reservations<\/span>
        \nbin\/magento inventory:reservation:list-inconsistencies -r | \\<\/span>
        \n\u00a0 bin\/magento inventory:reservation:create-compensations<\/span>\u00a0<\/span><\/p>\n

        Shorten the sync interval, or switch to events.<\/span><\/b> 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.<\/span>\u00a0<\/span><\/p>\n

        Set a safety buffer.<\/span><\/b> Use the <\/span>Out-of-Stock Threshold<\/span><\/i> (Stores \u2192 Configuration \u2192 Catalog \u2192 Inventory) to hold back a few units on fast movers.<\/span> Selling 98 of 100 units and shipping all of them beats selling 100 and cancelling three.<\/span>\u00a0<\/span><\/p>\n

        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.<\/span>\u00a0<\/span><\/p>\n

        <\/b>Step 2: Check cache, cron and indexers<\/span><\/b>\u00a0<\/span><\/h3>\n

        Know your cache hit rate.<\/span><\/b> With Varnish in front of Magento, most catalogue traffic should never reach PHP. <\/span>Measure it today so you have a baseline:<\/span>\u00a0<\/span><\/p>\n

        varnishstat -1 -f MAIN.cache_hit -f MAIN.cache_miss<\/span>\u00a0<\/span><\/p>\n

        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 <\/span>cacheable=”false”<\/span> in a layout file, which switches off the full-page cache for the whole page.<\/span>\u00a0<\/span><\/p>\n

        Keep sessions and cache apart.<\/span><\/b> 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. <\/span>In <\/span>app\/etc\/env.php<\/span>:<\/span>\u00a0<\/span><\/p>\n

        ‘session’ => [<\/span>
        \n\u00a0\u00a0\u00a0 ‘save’ => ‘redis’,<\/span>
        \n\u00a0\u00a0\u00a0 ‘redis’ => [<\/span>
        \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ‘host’ => ‘valkey-sessions’,<\/span>
        \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ‘port’ => ‘6379’,<\/span>
        \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ‘database’ => ‘2’,<\/span>
        \n\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0\u00a0 ‘max_concurrency’ => ’20’,<\/span>
        \n\u00a0\u00a0\u00a0 ],<\/span>
        \n],<\/span>\u00a0<\/span><\/p>\n

        Put every indexer on schedule.<\/span><\/b> “Update on Save” reindexes in the same request as the change. Under load, that is a bad idea.<\/span>\u00a0<\/span><\/p>\n

        bin\/magento indexer:set-mode schedule<\/span>
        \nbin\/magento indexer:status<\/span>\u00a0<\/span><\/p>\n

        Move work out of the checkout request.<\/span><\/b> Two settings that help when orders come in fast:<\/span>\u00a0<\/span><\/p>\n

        # Send order emails from cron instead of during checkout<\/span>
        \nbin\/magento config:set sales_email\/general\/async_sending 1<\/span><\/p>\n

        # Update the admin order grid asynchronously<\/span>
        \nbin\/magento config:set dev\/grid\/async_indexing 1<\/span>\u00a0<\/span><\/p>\n

        Watch cron, not just the storefront.<\/span><\/b> A stuck cron job won’t take the shop down. It will quietly stop emails, indexing and ERP exports. <\/span>This query shows what cron did in the last hour:<\/span>\u00a0<\/span><\/p>\n

        SELECT job_code, status, COUNT(*) AS jobs<\/span>
        \nFROM cron_schedule<\/span>
        \nWHERE scheduled_at > NOW() – INTERVAL 1 HOUR<\/span>
        \nGROUP BY job_code, status<\/span>
        \nORDER BY job_code;<\/span>\u00a0<\/span><\/p>\n

        Lots of <\/span>missed<\/span> or long-running <\/span>running<\/span> entries mean you have a problem to fix now, not in peak week.<\/span>\u00a0<\/span><\/p>\n

        Load test with real numbers.<\/span><\/b> Take last year’s peak hour from your analytics, multiply it by two or three, and test against staging, never production. <\/span>A short k6 script is enough to start:<\/span>\u00a0<\/span><\/p>\n

        import http from ‘k6\/http’;<\/span>
        \nimport { check, sleep } from ‘k6’;<\/span><\/p>\n

        export const options = {<\/span>
        \n\u00a0 stages: [<\/span>
        \n\u00a0\u00a0\u00a0 { duration: ‘5m’, target: 50 },<\/span>
        \n\u00a0\u00a0\u00a0 { duration: ’15m’, target: 300 },<\/span>
        \n\u00a0\u00a0\u00a0 { duration: ‘5m’, target: 0 },<\/span>
        \n\u00a0 ],<\/span>
        \n\u00a0 thresholds: {<\/span>
        \n\u00a0\u00a0\u00a0 http_req_duration: [‘p(95)<1500’],<\/span>
        \n\u00a0\u00a0\u00a0 http_req_failed: [‘rate<0.01’],<\/span>
        \n\u00a0 },<\/span>
        \n};<\/span><\/p>\n

        export default function () {<\/span>
        \n\u00a0 const base = __ENV.BASE_URL;<\/span>
        \n\u00a0 const res = http.get(`${base}\/`);<\/span>
        \n\u00a0 check(res, { ‘status 200’: (r) => r.status === 200 });<\/span>
        \n\u00a0 http.get(`${base}\/sale.html`);<\/span>
        \n\u00a0 http.get(`${base}\/catalogsearch\/result\/?q=jacket`);<\/span>
        \n\u00a0 sleep(1);<\/span>
        \n}<\/span>\u00a0<\/span><\/p>\n

        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.<\/span>\u00a0<\/span><\/p>\n

        <\/b>Step 3: Get delivery dates and discount prices right<\/span><\/b>\u00a0<\/span><\/h3>\n

        This part isn’t technical, but it ends up in your support inbox if you skip it.<\/span>\u00a0<\/span><\/p>\n

        Publish delivery cut-offs early.<\/span><\/b> Customers want to know one thing in December: will it arrive before the 24th? <\/span>Check your carriers’ Christmas cut-off dates, add a day of buffer for your own picking, and show the result in three places:<\/span>\u00a0<\/span><\/p>\n

          \n
        • a site-wide banner from early December<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
            \n
          • on the product page, next to the delivery estimate<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
              \n
            • in the checkout, before the customer pays<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

              Use a CMS block or widget for the banner so the shop team can update it without a deployment. That matters later, during the code freeze.<\/span>\u00a0<\/span><\/p>\n

              Check your strike-through prices.<\/span><\/b> In Germany, \u00a7 11 of the Price Indication Ordinance (PAngV) says that when you advertise a price reduction to consumers, the reference price must be the lowest price you charged in the previous 30 days. The European Court of Justice confirmed in September 2024 (C-330\/23) that this lowest price has to be the actual basis of the comparison. Percentage discounts are covered too.<\/span>\u00a0<\/span><\/p>\n

              For a Magento shop, that has two practical consequences:<\/span>\u00a0<\/span><\/p>\n

                \n
              • You need price history.<\/span><\/b> 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                  \n
                • Watch the “Special Price” field.<\/span><\/b> 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                  This is not legal advice. If your campaign uses unusual discount mechanics, have it checked.<\/span>\u00a0<\/span><\/p>\n

                  <\/b>Step 4: Freeze the code and plan for failure<\/span><\/b>\u00a0<\/span><\/h3>\n

                  Set a freeze date and stick to it.<\/span><\/b> 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.<\/span>\u00a0<\/span><\/p>\n

                  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.<\/span>\u00a0<\/span><\/p>\n

                  Write the incident plan down.<\/span><\/b> Not in someone’s head. <\/span>One page is enough, as long as it answers these questions:<\/span>\u00a0<\/span><\/p>\n

                    \n
                  1. Who is on call each day from 27 November to 31 December, and how do you reach them?<\/span>\u00a0<\/span><\/li>\n<\/ol>\n
                      \n
                    1. Who do you call at the hosting provider, the payment provider and the ERP partner? Have the numbers ready.<\/span>\u00a0<\/span><\/li>\n<\/ol>\n
                        \n
                      1. How do you roll back the last deployment, and how long does it take?<\/span>\u00a0<\/span><\/li>\n<\/ol>\n
                          \n
                        1. Who decides to switch on maintenance mode, and what does the customer see?<\/span>\u00a0<\/span><\/li>\n<\/ol>\n
                            \n
                          1. If orders stop reaching the ERP, how will you export them manually?<\/span>\u00a0<\/span><\/li>\n<\/ol>\n

                            Question 5 is the one nobody wants to answer, so answer it now. A CSV export of open orders from the Magento admin and a person who knows how to import it into SAP Business One will save you a very long night.<\/span>\u00a0<\/span><\/p>\n

                            Turn on the alerts you will actually read.<\/span><\/b> Uptime checks on the homepage are not enough. Alert on checkout errors, on payment failure rates, on cron jobs that haven’t run for 15 minutes, and on orders that haven’t reached the ERP within 30 minutes.<\/span>\u00a0<\/span><\/p>\n

                            <\/b>The checklist<\/span><\/b>\u00a0<\/span><\/p>\n

                            Print it, share it with the team, tick it off.<\/span>\u00a0<\/span><\/p>\n

                            <\/b>By 13 November<\/span><\/b>\u00a0<\/span><\/p>\n

                              \n
                            • Magento on a supported version with the November security patch installed<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                \n
                              • MSI reservation inconsistencies checked and fixed<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                  \n
                                • ERP stock sync running on deltas, every few minutes or event-based<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                    \n
                                  • Out-of-stock threshold set for fast-moving products<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                      \n
                                    • All indexers on “Update by Schedule”<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                        \n
                                      • Async email sending and async grid indexing switched on<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                                        <\/b>By 20 November (freeze)<\/span><\/b>\u00a0<\/span><\/p>\n

                                          \n
                                        • Varnish hit rate measured and cache-busting pages fixed<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                            \n
                                          • Sessions and cache on separate Redis\/Valkey databases<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                              \n
                                            • Load test passed at 2\u20133\u00d7 last year’s peak, including checkout and an ERP sync<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                                \n
                                              • 30-day lowest price recorded for every discounted product<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                                  \n
                                                • Delivery cut-off banner prepared as a CMS block<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                                    \n
                                                  • Incident plan written, on-call rota agreed, contacts collected<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                                      \n
                                                    • Alerts set up for checkout errors, payments, cron and ERP order export<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                                                      Need a second pair of eyes before 27 November?<\/span><\/b>\u00a0<\/span><\/p>\n

                                                      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.<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                                                      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 […]<\/p>\n","protected":false},"author":3,"featured_media":4018,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[17,18],"tags":[],"class_list":["post-4017","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-magento-2","category-magento-b2b-en"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t\n\t\n\t\n\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t\n\t\t