What is a code freeze?A stretch of days when only urgent fixes ship.
A code freeze is a period when a team stops shipping new changes to a product, usually production, and lets through only fixes that can't wait. Teams freeze before a big release, during a sales peak like Black Friday, and over the holidays when the people who wrote the code are away.
The idea is simple: fewer changes means fewer surprises at a moment when a surprise would hurt the most, or when nobody is around to deal with it. Below is what a freeze covers, the kinds you'll run into, the rules that make one work, and an announcement you can copy.
The short version
A code freeze has a start date and time, an end date and time, a list of what's still allowed (production fixes, security patches, reverts), one person who approves exceptions, and an on-call rotation that covers it. Everything else waits on a list until the freeze lifts.
Code freeze meaning, in one paragraph
In a code freeze, the main branch or the production deploy pipeline is closed to everything except changes the team has agreed are urgent. Work doesn't stop: people keep writing code on branches, reviewing and testing. It just doesn't ship until the freeze ends.
A feature freeze is a softer version: no new features go into a release, but bug fixes still do. A hard freeze or change freeze is stricter: nothing goes to production without an exception, often including configuration and infrastructure changes. When people say “code freeze” they usually mean something in between.
The kinds of code freeze teams run
Release freeze. A few days before a big release, the release branch is frozen so testing happens on code that isn't moving. Mobile teams do this before an App Store submission.
Peak season freeze. Retail and payments teams freeze around their busiest days. In 2026 that's Thanksgiving on Thursday November 26, Black Friday on November 27 and Cyber Monday on November 30, so a typical freeze runs from Monday November 23 to Tuesday December 1.
Holiday freeze. Most US teams freeze from the middle of December until the first Monday of January, because that's when the people who know each system are on vacation. For 2026, a common one runs from Friday December 18 to Monday January 4, 2027. See planning December releases around holiday leave for how to pick the dates.
Incident freeze. After a bad outage, some teams stop all changes until the root cause is fixed and the system is stable again.
What's allowed during a code freeze
Write the list down before the freeze starts, so nobody has to argue about it on December 23. A typical list: fixes for a production incident, security patches, reverting a change that broke something, and configuration changes the on-call engineer needs to keep things running.
What isn't allowed: new features, refactors, dependency upgrades, “tiny” copy changes and anything described as low risk. Most freeze incidents start with a change somebody was sure was safe.
Name one person who approves exceptions, and a backup for when they're out. An exception should be rare enough that everyone hears about it.
How long a code freeze should last
Long enough to cover the risky stretch, and no longer. A peak season freeze is usually a week. A holiday freeze is usually two weeks, from the last working Friday before Christmas to the first working Monday of the new year.
The longer a freeze runs, the bigger the pile of changes waiting at the end, and the riskier the first deploy back. Some teams thaw in stages: fixes first, small changes on day two, features after that. Whatever you pick, put an end date and time on it: “Monday January 4, 10:00 AM” is better than “early January”.
Before you lock the dates, check who'll actually be around. A freeze needs an on-call rotation, and the on-call person needs to not be on a plane. Leave clashes are easy to miss when the rotation and the vacation list live in different tools.
A code freeze announcement you can copy
Subject: Holiday code freeze, Dec 18 to Jan 4
Hi all, our holiday code freeze starts Friday December 18 at 5:00 PM ET and ends Monday January 4 at 10:00 AM ET. During the freeze only production fixes, security patches and reverts go out, and each one needs a thumbs up from Jordan (or Maya if Jordan is out). Anything else goes on the “waiting for January” list in the team channel. On-call for the freeze is in the team calendar. Thanks, and happy holidays.
Post it in your team channel two weeks ahead, pin it, and repeat it the day before the freeze starts.
Make the freeze hold
Lock the pipeline, not just the calendar
If your CI can block deploys to production during a date range, turn that on. A rule people have to remember is weaker than a button that's greyed out.
Ship the last release with room to fix it
Release on a Tuesday or Wednesday with at least three working days before the freeze, so the bugs it brings out land while everyone is still in.
Keep a waiting list
Every pull request that hits the freeze goes on one list with an owner. On the first day back it becomes the plan instead of a pile.
Check on-call against vacations
Every freeze needs someone on call. Make sure their shift doesn't land on their own time off or a public holiday where they live.
Write handoff notes
Everyone leaving writes three lines: what worries them, where the runbook is, and who else knows the system.
Thaw on purpose
Don't merge two weeks of changes in the first hour back. Fixes first, then small changes, then features.
A freeze is only as goodas the people around during it.
Most freezes fail in the same few ways: the dates are known but nobody checked who's out, and the on-call rotation lives somewhere else. Here's the same freeze on a Forgot board. It's live, so try moving someone's vacation into it.
Who's away during it
The board lists everyone who's out during the freeze, so you see that two of your five people are gone before the freeze starts, not during it.
On-call next to time off
On-call shifts sit on the same rows as vacations and public holidays, and a shift that lands on someone's own time off gets a warning.
Each person's holidays
Boxing Day in London and Diwali in Bangalore show up on the right rows, so the freeze isn't planned around one country's calendar.
- The freezes are bands across the whole team
- The summary names who's away during each freeze
- On-call shifts that clash with time off get a warning
- Drag your own days off in and see what changes
Plan the next freeze with everyone's time off in view.
Forgot puts each person's time off, on-call and public holidays on one timeline, with code freezes and release dates on top, and warns you when someone is out on a day that matters.
- Code freezes as team periods that name who's away
- On-call that warns when it lands on time off
- Release dates that warn when someone is out
- Public holidays for each person's country
Sign in with Google, no card. After the trial it's a one-time payment, not a subscription.
Questions
What is a code freeze?
A code freeze is a period when a team stops shipping new changes to production and only lets through urgent fixes, like a production incident fix, a security patch or a revert. Teams freeze before big releases, during sales peaks and over the holidays.
What's the difference between a code freeze and a feature freeze?
A feature freeze stops new features from going into a release but still allows bug fixes. A code freeze is stricter: no changes ship unless they're urgent and approved.
How long is a holiday code freeze?
Usually about two weeks, from the last working Friday before Christmas to the first working Monday of January. For 2026 that's Friday December 18 to Monday January 4, 2027.
Can you deploy during a code freeze?
Only what the freeze allows: fixes for production incidents, security patches, reverts and changes on-call needs to keep systems running, each approved by one named person. Everything else waits until the freeze ends.
Is a code freeze agile?
Teams that deploy many times a day often avoid long freezes, because small, frequent changes are safer than a big batch at the end. Many of them still freeze for a few days around peak traffic or the holidays, when the people who could fix a problem aren't around.