A change freeze is a dated window when you stop making non-essential changes to your store: no new app installs, no theme deploys, no checkout or shipping rule edits, no data migrations, no DNS changes. For most stores it should begin the week before Black Friday and lift after the last carrier ground shipping cutoff in December, with a short written list of exemptions so you can still fix genuine problems while it is in force.
The reason to write the freeze down now, in September, is that a freeze only works if the work you were going to do anyway happens before it starts. Declaring a freeze in the third week of November just means your risky changes get pushed into December, which is worse.
What does a change freeze actually prevent?
It prevents the class of outage you cause yourself and then misdiagnose as a vendor problem. During peak weeks your team is looking at a hundred dashboards, and a theme edit pushed at 11pm becomes a checkout bug that nobody connects to the deploy for two hours. A freeze removes that variable so that when something breaks, your first question is "which vendor" rather than "which of the nine things we changed today."
It also protects the parts of your stack you cannot test properly under load. Shipping rate logic, tax configuration, discount stacking rules, and subscription billing schedules all behave differently at ten times normal volume. A change made in October gets three weeks of real traffic to surface bugs. The same change made on Cyber Monday gets none.
What should the freeze calendar look like?
Use phases rather than one hard switch. The exact dates depend on your carrier cutoffs and your promo calendar, but the shape is the same for most stores.
| Phase | Window | What is allowed |
|---|---|---|
| Build | Now through the end of October | App installs and removals, theme rebuilds, checkout changes, tax and shipping rule edits, integration rewrites |
| Soak | Early to mid November | Bug fixes, copy and image updates, campaign setup, no new apps, no checkout or payment changes |
| Freeze | Week before Black Friday through the last ground shipping cutoff | Exemptions only, listed below |
| Thaw | After the final cutoff | Backlog released in small batches, one change per deploy, nothing on a Friday |
What stays exempt?
Write these down and share them with everyone who has admin access, including your agency and any contractor:
- Payment fallback toggles. Enabling or disabling a gateway or a buy now, pay later option at checkout is always allowed.
- Ad spend controls. Pausing or resuming campaigns is always allowed.
- Inventory, price, and stock status. Normal merchandising work continues.
- Carrier and rate switching. If one label API stops issuing labels, switching to a second one is a fix, not a change.
- Alert routing. Adding a phone number or a Slack channel to your on-call rotation.
- Security patches and genuine P1 fixes, with a named approver and a one-line entry in a shared log.
Which vendors should you ask about their own freeze window?
Your freeze does not bind your vendors. Shopify apps update server-side, payment providers deploy on their own schedule, and shipping APIs change without asking you. So the vendor management half of this job is asking each critical provider two questions: do you operate a code freeze during peak season, and what are its dates.
Prioritise by recent record rather than by how much you like the product. The figures below are from StatusBird's independent 2-minute monitoring over the 90 days ending September 19, 2026, and you can read how the checks work on the methodology page.
| Service | 90-day uptime | Grade | Major incidents | Downtime | Last incident |
|---|---|---|---|---|---|
| Plaid | 98.8% | C | 4 | 1,548 min | 2026-08-03 |
| Shippo | 98.96% | C | 10 | 1,344 min | 2026-09-17 |
| BigCommerce | 99.86% | B+ | 2 | 180 min | 2026-09-16 |
| ShipStation | 99.87% | B+ | 1 | 166 min | 2026-06-30 |
| Cloudflare | 99.89% | B+ | 2 | 142 min | 2026-08-12 |
| Shopify | 99.9% | A | 2 | 124 min | 2026-08-27 |
| Zapier | 99.91% | A | 2 | 118 min | 2026-09-09 |
Two patterns matter for freeze planning. Shippo recorded 10 major or critical incidents at an average of 134 minutes each, which is a frequency problem: you will probably hit one during a long sale weekend, and it will be short. Plaid recorded 4 incidents averaging 387 minutes, which is a duration problem: one event can swallow most of a trading day. Those two risks call for different preparation. Frequent short outages need a queue and retry plan. Long outages need a second provider you have already tested.
Monthly volume also moves a lot, so plan for a bad month rather than an average one. The outage index recorded 16 major or critical incidents and 40.4 hours of combined downtime across 9 services in August 2026, and 20 incidents totalling 122.1 hours across 11 services in April 2026.
What to send each critical vendor
One short email per vendor, sent in October while support queues are calm. Ask for written answers:
- Do you operate a production change freeze during the holiday period, and what are the start and end dates?
- What is the escalation path for a merchant of our size during that period, and does it differ from normal hours?
- What is your published uptime commitment, and what is the exact procedure and deadline for claiming a service credit?
- Do support response times change over the holidays, and is there a phone or priority channel?
- Which of your subprocessors or upstream providers would take your service down with them?
File the replies in one document with your account manager's name and direct contact. The value of that document is not the promises, it is having a named human to reach at 6am on Black Friday instead of a ticket form.
How do you cut dependency risk before the freeze starts?
Every app you keep is a vendor whose deploys you do not control. October is the month to shrink that surface:
- Uninstall what you are not using. Go through your app list and remove anything with no active use in the last quarter. Uninstall before the freeze, never during it.
- Identify the apps that touch checkout or storefront rendering. Those are the ones whose failures cost revenue directly rather than delaying a report.
- Pick a second option for each revenue-critical function. A backup payment method, a second label provider, a second way to send transactional email. Test each one with a real transaction and write down the toggle steps.
- Test your queue behaviour. If order sync to your fulfilment tool stops, confirm that orders queue and replay rather than silently dropping.
- Set alert routing before the freeze, including who receives SMS overnight and who covers the shift after them.
How do you exit the freeze without breaking things?
The thaw is where stores get careless. Release the backlog in order of blast radius, smallest first: content and copy, then merchandising logic, then app installs, then checkout and payments. One change per deploy, with a note of what it was and when, so that any January bug can be traced to a specific edit. Keep the freeze exemption log and read it once as a team, because the emergency fixes you shipped in November are usually quick patches that need a proper version.
One last item for the calendar: schedule the vendor review. Pull the incident record for each critical provider for the peak period, compare it against the uptime commitment you were given in October, and file any service credit claims before the vendor's deadline. That conversation is much easier when you have your own timestamps rather than a status page summary written days later.
If you want the vendor side of this watched for you, StatusBird checks Shopify, Stripe, Shippo, Plaid, and about 80 other e-commerce services every 2 minutes and alerts you by SMS, email, Slack, Teams, or Discord when one of them breaks. You can set up your watchlist and on-call routing before the freeze starts at statusbird.io/register.