I want to freeze the website during a sale so nobody accidentally pushes a change. How?

This page may contain affiliate links from which Blur Studio earns commissions.

This is a real, specific risk with any site where code changes auto-publish: someone on the team pushes a fix for something unrelated, maybe even something good, and it happens to go live three hours into your biggest sale of the year, right as traffic peaks. Nobody did anything wrong. The timing was just bad, and bad timing during a high-stakes window is exactly when you can least afford it.

What deploy locking actually does

Deploy locking pins your live site to whatever is currently published. Once locked, new code pushes to your repository still build on Netlify exactly as normal, your developers aren't blocked from working, but none of those new builds actually go live to visitors until someone deliberately unlocks the deploy. This is the difference between stopping work and stopping publishing, which matters: a team can keep preparing changes for after the sale ends, without any risk of one slipping through early.

Step by step: how to set this up

1. Decide the exact window you need frozen, and lock it before that window starts, not the morning of. A sale that begins at midnight needs the lock in place the evening before, not scrambled together at 11:58pm.
2. Go to the Deploys tab and select "Lock to stop auto publishing." This is a one-click action, reversible at any time.
3. Tell your team the lock is on and roughly how long it'll stay that way. This avoids confusion if someone pushes a change and is surprised it doesn't appear live; it built correctly, it just isn't published yet.
4. Let the sale or event run its course. Any genuinely urgent fix during the freeze can still be published manually by unlocking briefly, publishing, and locking again, which is a deliberate, visible action rather than an accidental one.
5. Unlock once the window ends. Select "Unlock to start auto publishing" and the pipeline resumes normally; whatever built up during the freeze can now go live.

What a lock does not cover

A deploy lock only controls what Netlify publishes from your connected repository. It does not stop changes made outside that pipeline entirely, such as a DNS change, an email campaign going out with a broken link, or someone editing settings directly in a different system your site depends on. If your "freeze" needs to cover more than code deploys, that needs its own separate plan and communication, not just a Netlify setting. A genuinely complete freeze checklist for a high-stakes window usually lists every system that could change customer-facing behavior during it: the code deploy pipeline, DNS, any third-party checkout or payment widget, email and ad campaigns scheduled to go out, and who specifically has the authority to make an exception if something urgent comes up. Writing that list out once, ahead of your first high-stakes freeze, means every future one just reuses it rather than reinventing it under time pressure.

What this actually costs

Deploy locking itself has no credit cost or special charge; it's a standard feature available on every plan. Notifications when a deploy is locked or unlocked (email, webhook or Slack alerts) are available specifically on Pro and Enterprise plans, worth having if more than one person could lock or unlock a deploy and the team needs visibility into exactly when that happened.

The one alternative, and its real limit

A written change-freeze rule for your team ("nobody pushes anything from Thursday night to Sunday morning") can work for a small, disciplined team, but it depends entirely on everyone remembering and following it under normal day-to-day pressure. A technical lock removes that dependency on memory; even a well-meaning accidental push simply doesn't go live during the freeze, no matter who forgot the rule.

When to skip this

For a very small team with infrequent deploys and strong internal communication already, a written rule might genuinely be enough, and setting up a technical lock is one more thing to remember to toggle. For anything high-stakes, a product launch, a major sale, a press moment, the technical lock is cheap insurance against a timing accident that a written rule alone can't guarantee against.

A worked example: a Black Friday near-miss

Say an online retailer has a developer finishing an unrelated bug fix the same week as their biggest sale of the year. The fix is good work, genuinely needed, and completely unrelated to the sale banner or checkout flow. Without a deploy lock, that fix merges and auto-publishes at 10am on Black Friday itself, at the exact moment traffic is highest, and even though the fix itself is fine, the deploy briefly interrupts the site while it switches over, a few seconds of risk during the single worst possible moment for any interruption at all. With a deploy lock in place from Thanksgiving evening through the end of the sale, that same fix builds normally and sits ready, fully tested and done, but doesn't touch the live site until the sale window closes and someone deliberately unlocks it.

Nobody in this scenario did anything wrong, the developer's timing wasn't careless, it just happened to land during a window that needed to stay untouched. That's exactly the kind of accident a technical lock removes entirely, rather than depending on every single person on a team remembering not to push anything during a specific multi-day window, which gets harder to guarantee as a team grows past a couple of people.

Common mistakes with deploy freezes

• Locking too late. Set the lock the evening before a midnight sale launch, not at the last minute, since a rushed lock setup is itself a small risk during the exact window you're trying to protect.
• Not telling the team the lock is active. A developer who pushes code expecting it to go live, and doesn't know about the freeze, will be confused when it doesn't appear, and may spend time debugging a "failed deploy" that actually succeeded, it's just intentionally not published yet.
• Assuming the lock covers everything related to the sale. A deploy lock only stops Netlify from publishing new code. Email campaigns, ad campaigns, third-party widgets and DNS all sit outside it, so a genuine full freeze needs its own checklist beyond just the one Netlify setting.

How I'd approach this

For any client running a predictable high-stakes window (a seasonal sale, a launch day, a press embargo lifting), I set up the lock as a standard part of the plan, not an afterthought scrambled together the night before. It's a two-minute setup that removes a genuinely avoidable risk entirely. Get in touch if you've got a high-stakes window coming up and want your deploy process locked down properly ahead of it.