Home › Blog › Black Friday Code Freeze 2026: What to Lock, What You Must Still Patch

Black Friday Code Freeze 2026: What to Lock, What You Must Still Patch

October 10, 2026 · 12 min read

A Black Friday code freeze is a fixed period before and during peak trading when you stop shipping non-essential changes to the store: no new plugins or apps, no theme changes, no checkout experiments, no platform upgrades for the sake of new features. In 2026 Black Friday falls on 27 November and Cyber Monday on 30 November, so most stores that follow that calendar will want the freeze to begin in early-to-mid November and the riskiest changes finished before then.

What a freeze must not do is block security fixes. Platforms and plugins keep shipping patches through the autumn, and some of them close holes directly in the payment path. The sensible plan is therefore not "change nothing" but "change only through a narrow, rehearsed exception route". This article gives you the dates, the rules, an exception test plan and the checks to run after any change that slips through.

At a glance

Do the risky work now: platform upgrades, plugin updates and integration migrations belong in October, not in the freeze window.
Freeze features, not security. Define in writing which fixes may still ship and who approves them.
Turn off unattended auto-updates on revenue-critical sites for the freeze window and replace them with a daily, human-reviewed update check.
Every emergency change gets the same short test: place a real order, confirm the payment, confirm the email, confirm the order count keeps moving.
Check integrations with fixed deadlines (for example product feed APIs) before the freeze, because they can fail on a vendor's schedule, not yours.

Why it matters now

Three things make October 2026 the right moment to plan the freeze rather than improvise it in November.

Platforms are still shipping security releases. As of October 2026, WooCommerce has released a major version roughly every month: 11.0.0 on 4 August, 11.1.0 on 1 September and 11.2.0 on 7 October, followed by 11.2.1 on 9 October. The 11.2.0 release notes state that it "includes security fixes" and ask merchants to update all stores; it also requires a database update. A release with a database migration is exactly the kind of change you want tested and live well before peak, not applied on the morning of Black Friday.

Payment plugins get vulnerabilities too. On 21 September 2026, CVE-2026-92400 was published for the Payment Gateway for PayPal on WooCommerce plugin before version 9.2.1. According to the advisory, the plugin did not verify that a payment notification came from the store's configured payment environment or was paid to the store's own merchant account before marking an order complete, which allowed an unauthenticated user to mark their own order as paid using a genuine transaction from a sandbox they controlled. It is rated medium (CVSS 5.3), but the effect is direct: orders that look paid and are not. If a fix like this lands in the middle of your freeze, you need a way to ship it the same day.

Some integrations break on the vendor's calendar. Google's Content API for Shopping was sunset on 18 August 2026. Since 1 September 2026, requests without an approved extension intermittently fail with HTTP 410 Gone, and Google says all endpoints will be turned down in early 2027. A feed app or custom script still on the old API may work most of the time and fail some of the time, which is the hardest kind of failure to notice during a busy week.

On WordPress, plugin and theme auto-updates can be enabled per plugin and, by default, run twice a day. That is a good security habit for most of the year. During a freeze it means a third party can change your checkout code at any hour without anyone on your side testing it.

Step-by-step: set up the freeze this week

Pick the dates and publish them. Write down the freeze start, the end (for example the Wednesday after Cyber Monday) and the time zone. Share it with everyone who can change the store: in-house staff, agencies, freelancers, app vendors with access.
Finish the risky work first. Before the freeze, apply pending platform and plugin updates in staging, test them, then deploy to production with at least one or two weeks of normal trading afterwards to surface problems. Treat any release that includes a database update as high risk.
Inventory what can change without you. List auto-updating plugins and themes, SaaS apps that update themselves, tag managers, A/B testing tools, payment provider settings, shipping rate tables and feed tools. Each is a way the store can change during a "frozen" period.
Switch auto-updates to reviewed updates. On revenue-critical WordPress sites, disable auto-updates for the freeze window on the Plugins screen and assign a person to review available updates once a day. Note which plugins touch checkout, payments, tax, shipping and order emails.
Check fixed-deadline integrations. Confirm your feed tool or script uses a supported API (for Google, the Merchant API), and review similar notices from your payment, shipping and email providers.
Define the exception route. Decide what qualifies (see the table below), who approves, who deploys, and the test that must pass. Keep it to two people so it can work at 22:00 on a Saturday.
Prepare rollback. Take a fresh backup before the freeze and confirm you can restore it. Keep the previous version of every critical plugin at hand.
Record a baseline. Note normal order volume per hour, payment success rate and email delivery for recent weeks, so that during the freeze "is this normal?" has an answer.

What to lock and what to allow

Change type	During freeze	Approver	Required check	When
New plugin, app or theme	Blocked	n/a	n/a	After freeze
Feature release, redesign, checkout experiment	Blocked	n/a	n/a	After freeze
Platform major version upgrade	Blocked unless it is the only security fix route	Store owner + technical lead	Full exception test plan	Before freeze, ideally
Security fix in checkout, payment or login code	Allowed via exception route	Technical lead	Full exception test plan	Same day as advisory, if exploitable
Security fix in a non-critical plugin	Allowed, or mitigate by deactivating	Technical lead	Smoke test + one test order	Within the agreed window
Content, prices, promotions, banners	Allowed (business as usual)	Ecommerce manager	Promotion check on a sample product	Daily
Tracking or tag manager changes	Blocked except fixes to broken tracking	Ecommerce manager + technical lead	Test order with tracking verified	Rarely
Payment, tax or shipping settings	Blocked except provider-mandated changes	Store owner	Full exception test plan	As required

Two notes on the table. First, a security fix is not automatically urgent: read the advisory, check whether the vulnerable feature is enabled on your store, and decide. Second, if you cannot patch safely, temporary mitigation (disabling a feature or a non-essential plugin) is also a change and goes through the same route.

Copyable artefact: emergency change test plan

Paste this into your ticket or chat before deploying anything during the freeze.

EMERGENCY CHANGE DURING FREEZE

Change:          [plugin/app/platform + old version -> new version]
Reason:          [advisory link / incident link]
Exploitable on this store? [yes/no + why]
Approved by:     [name]          Deployed by: [name]
Backup taken:    [time, location]   Rollback steps: [link or 3 lines]
Deploy time:     [time + time zone]

BEFORE DEPLOY (staging, if available)
[ ] Change applied on staging, no PHP/JS errors in logs
[ ] Test order with each payment method used in production
[ ] Database update (if any) completed without errors

AFTER DEPLOY (production, within 15 minutes)
[ ] Home, category, product, cart and checkout pages load
[ ] One real low-value order placed and paid with the main payment method
[ ] Order shows correct status in admin and at the payment provider
[ ] Order confirmation email received in an external inbox
[ ] Pages still indexable (no unexpected noindex), no unexpected redirects
[ ] Product feed still updating (last successful fetch/sync time checked)

WATCH (next 2 hours)
[ ] Orders per hour within normal range for this time of day
[ ] Failed/pending order rate not rising
[ ] Refund the test order; note the result in this ticket

Worked scenario (illustrative)

The following is an illustrative example, not a real customer case.

A store selling homeware runs WooCommerce with a third-party PayPal gateway plugin. The agency maintaining it freezes the site on 13 November. On a Thursday evening during the freeze, an advisory is published for the gateway plugin, describing a way to mark unpaid orders as paid.

The technical lead reads the advisory and confirms that the store uses the affected payment method, so the fix qualifies for the exception route. The owner approves by message. The lead takes a backup, applies the update on staging, places a test order, then deploys to production at 20:10. At 20:20 a real low-value order goes through; the order status in the admin matches the payment provider, and the confirmation email arrives in an external mailbox.

Over the next two hours orders per hour stay within the store's usual evening range. The test order is refunded and the ticket closed. Total effort: under an hour, with no feature changes mixed in. Without a pre-agreed route, the same fix would likely have waited until Monday, or been bundled with "while we're at it" changes that make a failure much harder to diagnose.

Common mistakes

Freezing too late. If upgrades are still being rushed through in the last days before the freeze, the freeze protects nothing. The risky work has to finish early enough for normal traffic to test it.
Freezing security along with features. A blanket "no changes" rule pushes people to either ignore a real advisory or bypass the process entirely.
Forgetting things that change themselves. Auto-updates, SaaS apps, tag managers and provider-side settings can alter the checkout without a deploy.
Bundling. An emergency fix plus "a small tweak" means two possible causes if orders drop.
Testing only that the page loads. A checkout page can load and still fail to take payment or send the confirmation email. Test the full order path.
No baseline. Without knowing normal order volume for a Friday evening, you cannot tell a quiet hour from a broken checkout.

Honest limitations: a freeze reduces the number of changes, not the number of failures. Payment provider outages, carrier problems, traffic spikes and third-party script failures can all happen with zero deploys. The freeze is one control alongside load preparation, monitoring and a clear incident plan, not a guarantee.

FAQ

When should a Black Friday code freeze start?

There is no single rule. A common approach is to finish platform and plugin upgrades in October and start the freeze one to two weeks before Black Friday, which in 2026 means early-to-mid November. Larger or more complex stores usually freeze earlier.

Should I turn off WordPress auto-updates before Black Friday?

For revenue-critical stores, replacing unattended auto-updates with a daily reviewed check during the freeze is reasonable, provided someone actually reviews updates and applies security fixes through the exception route. Turning auto-updates off and then ignoring updates is worse than leaving them on.

What if a security fix is released on Black Friday itself?

Read the advisory and decide whether the store is exposed. If it is, apply the fix (or a temporary mitigation) through the exception route with the full test plan, at the lowest-traffic hour you can reasonably wait for. If it is not exposed, schedule it for the day after the freeze ends.

Monitoring the freeze

The test plan above has two parts that are tedious to do by hand all week: is the store still taking orders at a normal rate, and did anything change right before a problem started. If you maintain WooCommerce stores, Pingvera can receive order events through its WordPress connector, compare order flow to an hourly baseline and alert when the site is up but orders have stopped; deploys and incidents appear on the same timeline as those order events, so an emergency patch and any drop that follows it sit side by side. It also watches for accidental noindex and unexpected redirects after releases. For the background, see catching a WooCommerce store that stopped selling and the unified timeline.

For the wider peak plan (demand modelling, load rehearsal, staffing), read the ecommerce peak sales readiness checklist; for the checks after any release, use the post-deployment website checklist; and for feeds, see product feed monitoring.

Sources

Last reviewed: 10 October 2026

Know about problems before your customers do

Pingvera watches whether an online business actually works — uptime, checkout, orders, domain, SSL and server — and alerts you in Telegram, email or a webhook before a customer has to tell you.

Start free

← All articles · Privacy policy · pingvera.com