Why Your Netlify Site Silently Stopped Updating (Auto-Publish Off)

The Silent Freeze: Green Builds, Stale Site

You push a commit. CI goes green. Netlify reports the deploy as "ready." Your site does not update. So you push three more commits. Three more "ready" deploys. And still the same old content sits live on your domain.

There is no error. No failed build. No red cross anywhere to grab your attention. Every signal you normally trust is telling you everything worked — and yet nothing you shipped is visible to a single visitor. This is one of the most disorienting failure modes in modern web deployment, precisely because it disguises itself as success.

What you are looking at is a Netlify site with auto-publishing disabled. The build pipeline is still running on every push, dutifully compiling your code and marking each result "ready." It just is not promoting any of those builds to production. They pile up in the deploy queue, green and untouched, while an older deploy keeps serving traffic.

The first time it happens, you will burn an hour second-guessing your code, your cache, your DNS — everything except the one setting that actually moved.

What Auto-Publish Actually Does

By default, Netlify runs a simple promise: every successful build of your production branch goes live automatically. Build succeeds, build publishes, done. That automatic promotion is what "auto-publishing" means, and it is on by default for a reason — it is the behaviour almost everyone expects from continuous deployment.

When auto-publishing is off, that final promotion step is severed. Netlify still listens for pushes. It still builds. It still validates. But the last link in the chain — "and now make this the live deploy" — no longer fires automatically. Instead, each finished build becomes a staged deploy waiting for a human to explicitly publish it.

This is genuinely useful in some workflows. Teams running a release-approval process, or sites where a person must sign off before production changes, deliberately turn auto-publish off. The problem is that the setting is sticky and invisible. Nothing in your day-to-day push-and-watch routine reminds you it is set.

So a feature designed for deliberate, gated releases becomes a trap for anyone who landed in that state by accident.

The Trigger: A Rollback You Forgot to Undo

Here is how almost everyone ends up here without meaning to: a rollback.

Something broke in production. You opened the Netlify dashboard, found a known-good earlier deploy, and clicked "Publish deploy" or "Restore" to roll back to it. The fire is out, the site is stable, you move on. What you may not realise is that manually publishing an older deploy can switch the site into a state where automatic promotion stops.

From that moment, every automated deploy is staging-only. Your incident response — the right call in the moment — quietly changed the rules for every push that follows. Days or weeks later, a completely unrelated change refuses to appear live, and the rollback you did during an outage is the last thing you would think to blame.

This is the heart of why the bug is so slippery: the action that caused it and the symptom it produces are separated by time, by context, and often by a different person entirely.

How to Confirm Auto-Publish Is Off

The good news is that confirmation takes about ten seconds once you know where to look. The symptom hides in the normal deploy list, but it is obvious the moment you check the right indicator.

Open the Netlify dashboard and go to Deploys. Scan the list for the deploy carrying the Published label. Now compare it to your most recent commit. If the Published badge is sitting on an older deploy while newer "ready" builds stack above it, auto-publishing is off. The newest green build is not the live one — and that mismatch is your entire diagnosis.

For a scriptable check, compare the live deploy's commit_ref field against your current git SHA. If they diverge while your latest build shows "ready," you have confirmed the freeze without ever opening a browser. This is the check worth automating, because the human eye glides right past a green build that simply is not the published one.

Two Fixes: One Deploy vs Permanent

There are two fixes, and which one you want depends on whether this was a one-off or an ongoing problem.

To publish a single deploy right now: open the deploy you want live, and choose Publish deploy. That promotes one specific build to production immediately. It does not change the underlying setting — the next push will still stage rather than publish — but it gets your current work live without delay.

To fix it permanently: go to Site configuration → Build & deploy and re-enable auto-publishing. From then on, every successful build promotes itself again, and the trap is closed.

If you script your deploys, the Netlify API exposes the same control. netlify api restoreSiteDeploy --data '{"deploy_id":"<id>"}' publishes a specific deploy by ID — handy when you are verifying and promoting deploys from a pipeline rather than clicking through the dashboard.

Trust the Live Site, Not the Build Badge

The deeper lesson outlives this one Netlify setting: a "ready" build is not a live site. Build status tells you compilation succeeded. It says nothing about what bytes a real visitor receives. Those are two different facts, and conflating them is what let four green deploys hide a frozen site.

If you run any CI/CD that pushes regularly, add a post-deploy assertion that closes the gap. Curl the live URL and grep for a unique string from the latest commit — a version number, a build hash, a fresh headline. If the string is not there, fail the pipeline loudly. That single check converts a silent, hour-eating mystery into an instant, unambiguous alarm.

The platforms we build on are full of settings that are correct in one context and quietly catastrophic in another. The defence is never "trust the dashboard." It is "verify the thing your users actually touch."

What's Next

This kind of invisible-state debugging is exactly the work that separates a site that ships reliably from one that surprises you. If you want a build and deploy pipeline that fails loud instead of failing silent, that is the standard we build to — see our website development service for how we approach it, and our take on web design and development best practices for the principles behind it.