guide
The Black Friday code freeze checklist.
Black Friday 2026 is Friday 27 November and Cyber Monday is Monday 30 November. Freeze from Wednesday 25 November to Tuesday 1 December, and start the work six weeks before that. Below is the whole thing as dated actions with an owner on each one, so it goes into a ticket rather than a document nobody opens.
the dates
When should a Black Friday code freeze start in 2026?
Wednesday 25 November, the day before Thanksgiving. Lift it on Tuesday 1 December, after Cyber Monday. The six dates that decide the window are below; the rest of the season is on the 2026 calendar.
| Date | What | Why it decides the window |
|---|---|---|
| Mon 16 Nov | Peak season starts | A sensible Monday to move to heightened review. Bigger changes get a second pair of eyes, deploys stay small. |
| Wed 25 Nov | Freeze starts (recommended) | The day before Thanksgiving. Start here rather than on the Friday. You want a full business day of quiet before the traffic, so you find out what the freeze itself broke. |
| Thu 26 Nov | Thanksgiving | Skeleton on-call in the US. If you need a hotfix today, you need an exception process that takes minutes. |
| Fri 27 Nov | Black Friday | The day the freeze exists for. |
| Mon 30 Nov | Cyber Monday | Usually the higher of the two for digital-only businesses. Freezing through Black Friday and thawing on the Sunday is the classic mistake. |
| Tue 1 Dec | Freeze lifts (recommended) | Thaw on the Tuesday, with people at desks, and stagger the queue rather than merging everything at 09:00. |
The dates are calendar facts. The recommended start and lift are ours, built from the fixed dates plus the staffing gaps around them. No published survey fixes them, and we are not going to invent one. download e-commerce-2026.ics ↓
the checklist
Six weeks out to the retro, with dates on it
Every line is an action somebody owns. The weeks are named by their Monday so the whole thing drops into a sprint without translation.
Six weeks out
week of Mon 12 Oct
owner: freeze owner
- Decide scope in writing: which services freeze, which keep shipping, and who decides a borderline case. A freeze whose scope is argued during the freeze is not a freeze.
- Name two people. The freeze owner is not the exception approver. One person holding both roles approves their own hotfix at 21:00 on the Friday, which is how the record stops meaning anything.
- Publish the dates internally, and publish the END date more prominently than the start date. Everyone remembers when a freeze starts. Nobody remembers when it lifts.
- Audit what would actually block a merge today. Open a throwaway pull request against your release branch and try to merge it. Configuration you have never tested is a plan, not a control.
Four weeks out
week of Mon 26 Oct
owner: tech leads
- Land the risky migrations now, or defer them to January. There is no third option, and the decision is cheaper this week than it will be in three.
- Deploy something on purpose. A deploy path that has not run for four weeks is where the emergency fix fails, and you want to find that out in October.
- Check on-call against the window, including the thaw day. The Tuesday after Cyber Monday needs more people than a normal Tuesday, not fewer.
- Ask the teams outside the freeze what they depend on inside it. Shared libraries and internal APIs are where an out-of-scope team discovers it was in scope.
Two weeks out
week of Mon 9 Nov
owner: freeze owner
- Turn the advisory band on from Mon 16 Nov. Bigger changes get a second reviewer, deploys stay small, nothing is blocked yet.
- Say it in the channels people actually read, and put the end date somewhere a product manager without GitHub access can see it.
- Dry-run the exception process with a fake hotfix. Do this one. It is the item that finds the broken part, and it takes twenty minutes.
- Write down what a hotfix is. If the definition is "whatever the loudest person says", the exception path will be used for a copy change on the Friday.
Freeze week
Wed 25 Nov to Tue 1 Dec
owner: freeze owner
- Start on the Wednesday, not the Friday. You want one quiet business day to find out what the freeze itself broke.
- Be explicit about what frozen covers: merges, deploys, infrastructure changes, and feature flags. Flags are usually the deliberate exception, and that belongs in writing rather than in an assumption.
- Keep the record in one place. Every override, who granted it, why, and when it expired. On the Monday after, that record is the only honest account of the week.
- Do not thaw on the Sunday. Cyber Monday, Mon 30 Nov, is the higher day for a lot of digital-only businesses.
Thaw day
Tue 1 Dec
owner: tech leads
- Treat it as the most dangerous deploy of the year, because it is: everything the freeze queued goes out into a team that has not deployed in a week.
- Order the queue by risk and stagger it. Merging everything at 09:00 turns a week of caution into one bad afternoon.
- Have people at desks who can roll back, and do not thaw on a Friday.
After
week of Mon 7 Dec
owner: freeze owner
- Count four numbers: pull requests queued at the thaw, hotfixes that needed an exception, incidents in the 72 hours after the thaw against a normal week, and hours from "we need this in" to "it merged".
- Write them down for next year, including the uncomfortable answer. If the freeze bought you nothing measurable, next year’s band should be shorter.
enforcement
What actually blocks a merge on Black Friday?
Whatever GitHub is enforcing on the branch, and nothing else. A freeze announced in Slack blocks nobody. Read the effective rules on the branch you care about, and read them from the API rather than from the settings page, because the settings page shows what you configured and the API shows what applies.
gh api \
repos/acme/storefront/rules/branches/main \
--jq '.[] | {type, source: .ruleset_source}'An empty array means nothing is enforced, whatever the announcement said. Run it on every branch in scope during the six-weeks-out audit, not on the Wednesday.
If the audit turns up nothing enforced, you have two honest options. Write the ruleset yourself, which the rulesets guide walks through with the commands, and turn it on and off by hand. Or use Fwozen, which puts the window on a schedule with a timezone attached, fans the result out to every open pull request, and keeps the record of who granted each exception and why. Scheduled and recurring freezes are in the free tier.
questions
Questions this page exists to answer.
When should a Black Friday code freeze start in 2026?
Wednesday 25 November 2026, the day before Thanksgiving. Black Friday is Friday 27 November and Cyber Monday is Monday 30 November, so a freeze that starts on the Friday has no quiet day in it. Starting on the Wednesday gives you one full business day to discover what the freeze itself broke, which is the failure people do not plan for. Lift it on Tuesday 1 December, after Cyber Monday.
How long should a Black Friday freeze last?
Five business days covers it: Wednesday 25 November to Tuesday 1 December. The cost of a freeze grows faster than the days you add, because every extra day is another day of queued changes that all thaw at once. If you need three weeks to feel safe over one weekend, the thing to fix is the deploy path, not the calendar.
What counts as an emergency during a code freeze?
Write the definition down before the freeze starts, and keep it narrow: customer-facing breakage, data loss, or a security fix. Then make the path fast. An exception that takes an hour of arguing gets routed around, and a freeze people route around produces lies rather than safety. Name the approver, require a written reason, and give the exception an expiry so it cannot quietly become permanent.
Should the deploy pipeline be frozen as well as merges?
Yes, and this is the gap that catches teams. A merge freeze with a live deploy pipeline still ships whatever was merged before the freeze, plus anything a scheduled job promotes. Gate the pipeline on the same freeze state as the merge, or you have half a control and full confidence.
Do code freezes actually reduce incidents?
Not the way most people assume, and it is worth being honest about that before you spend a week of everyone’s time. The deployment-frequency research points the other way, and the thaw concentrates risk into a single day. What a freeze buys is lower variance on a date where the downside is enormous, and a smaller on-call load while half the team is away. We wrote the long argument against our own product if you want the other side properly made.
what this page is not
There is no policy template here yet. We want to publish a copy-pasteable freeze policy covering scope, banding, approvers, the exception process and audit requirements, and we have not written it. Mail [email protected] if you want it and we will move it up.