The build passes and the host reports a successful deploy, but production doesn't match what ran on your machine. A stylesheet or JavaScript chunk is missing, serverless functions hang until they time out, an alias serves an old build, or pushes stop deploying. We have 21 verified builder reports of this pattern, across several hosts and frameworks.
The host runs a clean install and build in its own container, with its own Node.js version, package manager and build cache. Without a committed lockfile, a caret range such as ^4.0.0 can resolve to a newer release than the one on your machine. A framework upgrade can also change where the build writes its output. The host uploads whatever is in the configured output directory, even if your assets were written somewhere else.
Hosts restore the previous build's cache before the install and build commands run. On Vercel the cache key includes the project, framework preset, root directory, Node.js version, package manager and Git branch. Changing any of these, or caching a broken intermediate state, can produce output that differs from a clean local build.
A browser that loaded the HTML before a deploy still references the previous build's hashed chunk names. Once the old assets are removed, that page's next dynamic import fails. The Vite docs describe this case and recommend Cache-Control: no-cache on HTML files so browsers stop referencing old assets.
A serverless function times out when it never returns a response, or when an API or database it calls responds slowly or not at all. A missing environment variable, a database that refuses connections from the host's network, and a code path that ends without sending a response all look like a hang from the outside. Pages prerendered at build time can also call live APIs during the build, so the deploy depends on those APIs being reachable at that moment.
After a Vercel Instant Rollback, auto-assignment of production domains is turned off, so new pushes to the production branch do not replace the rolled-back deployment. Deploys also stop when the repository webhook is gone, the Git connection has lapsed, an Ignored Build Step script exits 0, or git.deploymentEnabled is false. When frontend and backend deploy on separate schedules, they can also go live in the wrong order.
Commit the lockfile and install with npm ci, which fails if package-lock.json and package.json disagree and never rewrites either file. Pin the Node.js version too: Netlify reads .nvmrc or .node-version before falling back to its own default.
node --version > .nvmrc
git add package-lock.json .nvmrc
# locally, in CI and as the host's install command
npm ciDelete node_modules and the build output, run npm ci and the same build command the host runs, then serve the output directory with a static server, not the dev server. On Vercel, compare the result with the deployment's Source tab (or /_src on the deployment URL) and the Resources tab, which lists the functions, middleware and assets that were actually built.
If the clean local build is correct and production is not, rule out the cache. On Vercel, redeploy with 'Use existing Build Cache' unchecked, run vercel --force, or set VERCEL_FORCE_NO_BUILD_CACHE=1. On Netlify, deploy the latest branch commit with the clear cache option.
vercel --forceServe HTML with Cache-Control: no-cache, and reload the page once when a chunk fails to load. On Vercel, Skew Protection pins framework-managed asset and navigation requests to the deployment that served the page. It supports Next.js, SvelteKit, Qwik, Astro and Nuxt on the Pro and Enterprise plans.
window.addEventListener('vite:preloadError', () => {
window.location.reload()
})Fetch the HTML, one real asset it references, and one function or data endpoint, with a timeout. curl -f fails on any HTTP status of 400 or above, so a 404 or 504 fails the script and the release. Adjust the asset pattern to your framework's output path.
set -e
URL=https://your-domain.example
curl -fsS "$URL/" -o /tmp/index.html
ASSET=$(grep -oE '/assets/[^"]+\.js' /tmp/index.html | head -1)
curl -fsS "$URL$ASSET" -o /dev/null
curl -fsS --max-time 10 "$URL/api/health"Ship the API or database change before the frontend that depends on it. Keep old fields and endpoints working until no deployed client uses them. Make every function return a response on every path, including errors, so a failure shows up as a status code instead of a timeout.
On Vercel, check the production deployment tile for an Undo Rollback button. Use it, or promote a deployment, to turn auto-assignment back on. Then check the repository's webhooks for the host's entry (disconnect and reconnect the repository if it is missing), the Git login connection, the production branch setting, the Ignored Build Step script, and git.deploymentEnabled in vercel.json.
vercel promote <deployment-url>A passing build only proves that the build command exited successfully. It does not check that the output directory holds the files your HTML references, or that functions can reach their database and environment variables at runtime. The post-deploy smoke test checks those.
Only people who loaded the page before the deploy are affected. Their HTML references the previous build's hashed chunks, and once those are removed, their next dynamic import fails. Serve HTML with Cache-Control: no-cache and reload once on vite:preloadError, or use Skew Protection on Vercel.
Yes, but builds get slower. Rebuild once without the cache to confirm or rule it out as the cause. If the cache is the cause, fix the input that differs, such as an unpinned Node.js version or a missing lockfile.
A rollback turns off auto-assignment of production domains. New deployments still build, but they do not go live. Use Undo Rollback on the production deployment tile, or vercel promote, to turn auto-assignment back on.