How to Announce a Code Freeze to Your Engineering Org

Announcing a code freeze well is mostly about timing and completeness. Send it too late and engineers rush risky changes through before the window. Leave out the override process and you will answer the same question in Slack six times in the first week.

This post covers when to announce a freeze, what to include, which channels to use, and a Slack message template you can copy and adapt.

When should you announce a code freeze?

Announce the freeze at least two weeks before it starts. That lead time lets engineers front-load high-risk work, avoid scheduling large migrations inside the freeze window, and set up on-call rotations around it.

A last-minute announcement (day-of or one or two days out) predictably triggers a surge of late deploys from engineers trying to beat the window. Those rushed changes tend to cause the exact incidents the freeze was meant to prevent.

For recurring seasonal freezes (December holidays, end-of-quarter, peak traffic periods), the announcement can go out even further in advance, three to four weeks, since the date is known well ahead of time. Include a reminder 48 hours before the freeze activates.

What to include in the freeze announcement

Every freeze announcement should answer five questions:

Question	What to write
What is frozen?	Specific repos and environments (not "everything")
When does it start and end?	Exact timestamps with the time zone spelled out
What is not frozen?	Explicitly name low-risk repos staying open
How does enforcement work?	Automated via required status checks, or Slack-only
How do I get an exception?	Who approves, what to submit, expected response time

The enforcement method is worth stating explicitly. Engineers who have lived through soft freezes enforced only by Slack announcements will assume this one works the same way. If merges are actually being blocked by a required status check, say so. It reduces override requests from engineers who did not realize the freeze was technically enforced, and it builds trust that the freeze will hold.

A Slack message template that works

Here is a template you can adapt. It covers all five questions, takes about one minute to read, and avoids the passive bureaucratic tone that makes engineers skim past freeze announcements.

---

Subject / thread title: Code freeze [DATES] — [scope]

Hi team,

We are running a code freeze from [START DATE, TIME, TZ] through [END DATE, TIME, TZ].

What's frozen:

• Production deployments for [list of services/repos]
• Merges to main on [list of repos]

What's not frozen:

• [Internal tools], [docs repo], [low-risk services] — these stay open
• Fixes to existing branches are fine; only new merges to main are blocked

How it's enforced: Merges are blocked automatically via a required status check. You will see the check fail on any open PR during the window. This is not a Slack-only freeze.

If you need an emergency exception: Post in [#freeze-exceptions] with:

1. What you need to merge and why it cannot wait
2. A second approver (your manager or the on-call lead)

Exceptions are targeted — approving your request unlocks your specific PR, not the whole freeze.

The freeze lifts automatically on [END DATE, TIME, TZ].

[Your name]

---

Adjust the repo list and the exceptions channel to match your setup. The key structural choices, explicit scope, exact timestamps, a named override channel, and a note that enforcement is automatic, are the parts that cut down on follow-up questions.

Follow-up messages: a simple cadence

One announcement is not enough. A three-message cadence works well:

1. Two weeks before: The full announcement above
2. 48 hours before: A short reminder with the start time, the scope, and a link to the original message
3. At lift: A brief "the freeze has ended" note with a reminder to coordinate on held-back changes before shipping everything at once

The 48-hour reminder does the most work. By that point, engineers who missed the first message see it, and engineers with queued risky work get a second chance to hold off. Keep it to three or four lines.

The lift message is easy to skip but worth doing. Teams running through a deploy backlog after a freeze benefit from a heads-up that the window is closed and the surge is starting. It lets them coordinate on sequencing rather than shipping everything simultaneously. The post-freeze deploy backlog guide covers that sequencing in detail.

Which channels to use

A dedicated #code-freeze or #freeze-exceptions thread keeps the conversation searchable and avoids burying the announcement in high-volume channels. Engineers can subscribe for updates without watching the main engineering channel for freeze-related replies.

Your main engineering Slack channel for the initial announcement, not just the channel where engineering managers post. Engineers read their team channels. The announcement needs to reach individual contributors.

Email for larger or distributed teams if a significant portion of the org checks email more reliably than Slack. Include a link to a shared doc with the freeze details so it is findable after the Slack thread scrolls away.

Do not rely on a project management tool notification or a calendar invite as the primary channel. Engineers may not have the relevant calendar or board in their daily flow.

What to say about overrides before the freeze starts

If your freeze is technically enforced, the override process needs to be discoverable before it starts, not just buried in the original announcement. Pin a message in the exceptions channel that explains:

• Where to post an override request
• What to include (the PR link, the reason, the second approver)
• Who is on rotation to approve during business hours and after hours
• The expected response time (something like "30 minutes during business hours, on-call lead handles overnight")

Engineers will not scroll back through the announcement thread at midnight during a production incident. A pinned note in the exceptions channel is faster to find and reduces friction at the worst moment. The emergency deploy override guide covers the approval workflow and audit trail requirements in more depth.

Where tooling fits in

For teams on GitHub, the gap between a Slack-announced freeze and a technically enforced one is a webhook listener that posts a failure status to the GitHub Commit Status API for every open PR while the freeze is active. New PRs opened during the freeze need the check posted on creation, which requires a persistent listener, not a one-time script.

NoShip automates this at the org level: it posts the required status check to all connected repositories, handles PRs opened mid-freeze, runs RRULE-based freeze schedules automatically, and provides a dual-approval override path with a full audit log. Slack notifications for freeze activations and overrides are built in, which means the communication cadence above happens without you manually posting each message.

The concepts guide covers how freeze windows and override flows work. For the scope, duration, and enforcement design decisions that precede the announcement, the code freeze best practices checklist is worth reading alongside this one.