Holiday Code Freeze: Shipping Safely in December

December is a strange month for a startup product team. Customers are busy, half your engineers are about to take time off and the cost of a broken release goes up just as the number of people who can fix it goes down. A holiday code freeze is a simple agreement to slow or pause changes for a few weeks. Done well, it protects customers and gives your team a real break. Done badly, it just moves the chaos to January.

Big companies have run change freezes around peak periods for years. Startups often skip them because "we are small and we move fast." That is exactly why a light version helps. When three people hold all the knowledge about your payments flow and two of them are on a plane, a deploy that breaks checkout can sit unfixed for days.

This guide walks you through a practical, startup-sized freeze: what to include, how to handle the urgent fix that will inevitably appear and how to come back in January without a pile-up of risky releases.

What a holiday code freeze is (and is not)

A code freeze is a team agreement that, for a defined window, normal releases stop and only specific types of change are allowed into production. It is not a ban on working. Engineers can keep writing code, reviewing pull requests and testing on staging. What changes is what reaches your customers.

Most teams choose one of three levels:

• Soft freeze. Releases continue, but only small, low-risk changes with a second reviewer. Large features wait.
• Hard freeze. No production changes except approved emergency fixes and security patches.
• Staged freeze. A soft freeze in early December, a hard freeze over the main holiday dates, then a soft period again in early January.

The right choice depends on your business. A tool used mostly by offices may see quiet traffic over Christmas and New Year. An online shop, a booking platform or a gift product may hit its busiest weeks in December, which is precisely when you want the fewest surprises.

Why it matters for small teams

Your risk is not only the bug itself. It is the time to notice it and fix it. Over the holidays, fewer people are watching dashboards, support responses slow down and the person who wrote the code may be unreachable. A freeze reduces the chance of a problem while you have the least capacity to handle one.

Setting your freeze dates and scope

Start by looking at the calendar and your own traffic patterns. Christmas Day is 25 December and Boxing Day is 26 December, and in the UK the Boxing Day bank holiday moves to a weekday when it falls on a weekend. Hanukkah also falls in late December in 2027, so check the exact dates for your team. Map these against who is on leave, which customers are most active and any year-end deadlines your product supports.

1. Pick the window. Many startups choose a hard freeze from around the middle of December until the first working days of January. Adjust to your own traffic and staffing.
2. Set a "last big release" date. Choose a date a week or more before the freeze starts. Major features must be live by then, or they wait until January.
3. Define what is allowed. Write a short list: security patches, fixes for customer-impacting bugs, legally required changes and content updates that do not touch code.
4. Name the approvers. Pick one or two people who can approve an exception, with a backup for each day of the freeze.
5. Publish the plan. Share it in your team channel, add it to the shared calendar and pin it where people will see it.

The exception process for urgent fixes

Something will break during the freeze. A partner changes an API, a certificate expires or a customer finds a bug that blocks their work. You need a fast, calm way to decide whether a fix goes out.

A simple exception process asks four questions:

• What is the customer impact? Is someone blocked, losing data or unable to pay, or is it cosmetic?
• Is there a workaround? Could support help customers manage until January?
• How big is the change? A one-line config fix is different from a database migration.
• Can it be rolled back? If the fix fails, how quickly can you undo it?

If the impact is high and the change is small and reversible, approve it, deploy during working hours when the on-call engineer is available and watch it closely afterwards. If the change is large or hard to reverse, look for a workaround first.

Feature flags help, but do not replace judgment

If you already use feature flags through a tool such as LaunchDarkly, Unleash or Flagsmith, you can ship code dark before the freeze and switch a feature on later, or switch a problem feature off without a deploy. Treat flipping a flag in production as a change too, and route it through the same approval. Check each tool's current features and pricing if you are still choosing one.

On-call, monitoring and rollback plans

A freeze reduces risk, but it does not remove it. Infrastructure still fails, third-party services still have outages and traffic can still spike. Before the freeze starts, make sure someone is responsible every day and knows what to do.

Build a fair on-call rota

Ask the team about leave first, then build the rota around it. Spread holiday days fairly, swap where people prefer certain dates and make sure each shift has a named backup. Agree how on-call time is recognized, such as time off in lieu or extra pay, in line with your policies and local employment rules. This is general information, not legal advice, so check the rules where your team works.

Check your monitoring

• Confirm alerts reach the on-call person's phone, not just a team inbox nobody is reading.
• Test the alerts for your most important flows, such as sign-up, login, checkout and data sync.
• Renew any certificates, domains or API keys that expire in late December or early January.
• Check any scheduled jobs that run at year-end, such as annual reports, renewals or date-based billing.

Write the rollback steps down

The person on call may not be the person who knows the system best. Write a one-page runbook for each critical service: how to roll back the last release, how to restart it and who to call if that fails. A tired engineer at 9 p.m. on 27 December will thank you.

Communicating with customers during the freeze

Customers rarely need to know about your internal release schedule, but they do need to know how support works over the holidays. Tell them in advance.

• Support hours. Share any reduced hours and response times in your help center and email footer. Help desk tools such as Zendesk or Help Scout let you set holiday schedules and auto-replies.
• Status page. If you have one, through a tool such as Statuspage or Better Stack, make sure the on-call person can post updates quickly.
• Planned work. If a feature a customer is waiting for will now ship in January, tell them directly rather than letting them discover it.

Using the freeze productively

A freeze does not have to be dead time. Engineers who are working can tackle valuable work that does not touch production right away:

• Pay down technical debt on branches that will be reviewed in January.
• Improve automated tests, especially for flows that caused incidents this year.
• Update documentation and runbooks.
• Run a short incident review of the year and pick two or three reliability improvements.
• Prototype ideas for next quarter without the pressure to ship.

It is also a good moment to rest. If your team has been shipping hard all year, a quieter December can do more for next year's output than any extra feature.

A freeze plan template

Copy this into your team wiki or a shared document. The dates and names are made-up examples for illustration only.

Planning the January thaw

The riskiest week can be the first one back. Branches have piled up, people are rusty and everyone wants to ship their work at once. Plan the restart deliberately.

1. Hold a short kickoff. Review any incidents and exceptions from the freeze.
2. Order the queue. List waiting changes and release them in small batches, smallest and safest first.
3. Avoid big-bang releases. Spread large features over the first few weeks, with monitoring after each.
4. Check year-change bugs. Look for anything that depends on the new year, such as date pickers, reports or annual billing.
5. Capture lessons. Note what worked and what to change for next year's freeze.

Frequently asked questions

The bottom line

A holiday code freeze is a small piece of planning that protects your customers and your team at the same time. Set the dates and scope now, land big work early, keep a fast exception process for real emergencies and make sure someone is on call with clear runbooks.

Then plan the thaw just as carefully, releasing in small batches when everyone is back. Your product stays steady through December, and your team starts January rested instead of firefighting.