← ./articles

Wrangler Says Deployment Complete but Exits 1: Verify Before Retrying

cloudflare-pageswranglerdeploymentcidebugging

Sometimes a deploy command gives you two opposite signals.

Wrangler may print a successful Cloudflare Pages deployment message, then the process still exits with code 1. If you only look at the exit code, you may retry a deployment that already went live. If you only look at the success text, you may miss a real failure.

The fix is to verify the deployment result explicitly before changing app code or retrying blindly.

The confusing signal: success text plus exit code 1

The pattern looks like this:

✨ Deployment complete!

Then your shell, npm script, or CI job reports failure because the process returned 1.

This matters because build and deploy pipelines often treat any non-zero exit as a hard failure. That is normally correct. But with deployment CLIs, the authoritative state may be the remote platform after the upload, not the local process status alone.

Separate build success from deploy success

Before investigating Wrangler, confirm that your build artifact is fresh:

Remove-Item -Recurse out -ErrorAction SilentlyContinue
npm run build
Get-ChildItem out

If the output directory was not recreated, stop there. That is a build problem.

If out/ or dist/ is fresh and Wrangler printed deployment completion, the next question is not "which source file is broken?" It is "what did Cloudflare publish?"

Verify with Cloudflare deployment state

Check the deployment list:

npx wrangler pages deployment list --project-name my-site

Look for the newest deployment time and environment. Then check the public URL:

$resp = Invoke-WebRequest https://my-site.pages.dev/ -UseBasicParsing
$resp.StatusCode
$resp.Content.Substring(0, [Math]::Min(200, $resp.Content.Length))

For a static site, also verify a changed file that proves the new artifact is live. Examples:

Invoke-WebRequest https://my-site.pages.dev/feed.xml -UseBasicParsing
Invoke-WebRequest https://my-site.pages.dev/sitemap.xml -UseBasicParsing

Do not rely on the home page alone if caches or old content could hide the issue.

Decide what the pipeline should do

Classify the result:

  • build failed: fix the app or build environment
  • Wrangler failed before upload: inspect cwd, auth, output path, and network
  • upload completed but exit code is wrong: verify remote state, then record the CLI mismatch
  • live URL is stale: treat deployment as failed even if the CLI printed success

In CI, you may still want the job to fail on exit code 1. But the human response should be different when the production URL is already updated.

A useful deploy script can print a second verification phase:

Wrangler exited with code 1 after printing deployment completion.
Checking Cloudflare deployment list and live URL...
Live URL contains expected build marker: yes

That turns an ambiguous failure into a documented platform or CLI mismatch.

Avoid changing app code from deploy-status noise

An exit-code mismatch after upload is not evidence that:

  • your Next.js routes are broken
  • your static export is malformed
  • your Pages project must be recreated
  • Wrangler should be downgraded immediately
  • the same deployment should be retried repeatedly

Those may become relevant later, but first verify the deployed artifact.

What to save in logs

When this happens, save:

  • Wrangler version
  • Node version
  • operating system
  • exact deploy command
  • whether Deployment complete appeared
  • exit code
  • newest deployment from wrangler pages deployment list
  • HTTP status and a content marker from the live URL

That evidence is more useful than a raw "deploy failed" note.

References