Deleted Pages deployment hostname continues serving assets

[codlp]

Which Cloudflare product?

Pages (Direct Upload)

Wrangler version

4.120.0

What happened?

A Pages deployment was deleted successfully and no longer appears in either wrangler pages deployment list or the Cloudflare Pages deployments API. More than 20 hours later, its hash-based *.pages.dev deployment hostname still returns HTTP 200 and serves the deployment's original static assets.

Retrying deletion with the original full deployment UUID now returns API error 8000009 (“The deployment ID you have specified does not exist”), while the deployment hostname remains live.

The current production deployment and custom domain are behaving correctly. I am withholding the account, project, deployment UUID, and hostname from this public issue because the stale deployment contains internal analytics exports. I can provide those details privately to a Cloudflare maintainer.

Expected behavior

Deleting a Pages deployment should make its hash-based deployment hostname and assets unavailable, ideally returning 404, within a documented propagation window.

Reproduction

1. Direct-upload a Pages deployment containing a uniquely identifiable static file.
2. Delete that non-current deployment using Wrangler or the Pages API.
3. Confirm it disappears from deployment listing.
4. Request https://<deployment-hash>.<project>.pages.dev/<file>.
5. Observe that the deleted deployment may continue serving the file.

Additional context

The project uses Pages advanced mode (_worker.js) and Direct Upload. The stale asset is served directly from the deleted deployment hostname. Repeating the DELETE request cannot invalidate it because the API considers the deployment nonexistent.

[workers-devprod]

Note

This is an automated, advisory triage report generated by workers-devprod. It is not an official maintainer response — a maintainer will follow up.

🤖 Automated triage report

Issue Triage: #67

Summary

A deleted Pages (Direct Upload) deployment's hash-based *.pages.dev hostname keeps serving the deployment's original static assets more than 20 hours after the deployment was successfully deleted and removed from all listings.

Classification

• Type: Bug
• Component: packages/wrangler (Pages code lives in wrangler), but the failing behavior is Cloudflare Pages edge/platform-side, not a Wrangler CLI defect
• Severity: High
• Has Reproduction: Yes (clear 5-step reproduction in the issue; maintainer has since independently reproduced it)
• Quality: Complete

Findings

• Created: 2026-08-07
• Author: codlp
• Version: wrangler 4.120.0
• Labels: product:pages, api
• Comments: 3

Analysis

• The report is complete and well-written: product (Pages Direct Upload), Wrangler version (4.120.0), expected vs. actual behavior, and a clear five-step reproduction. The reporter withheld the account/project/UUID/hostname because the stale assets are sensitive internal analytics exports, and offered to share them privately.
• Deletion itself works correctly — the deployment disappears from wrangler pages deployment list and the Pages API, and a repeat DELETE returns API error 8000009 ("The deployment ID you have specified does not exist"). Wrangler is issuing the correct API call; the deletion is registered server-side.
• The persistent symptom is the *.pages.dev edge continuing to serve assets ~20h after deletion. This is Cloudflare Pages edge/asset-serving behavior — no client-side action (repeat DELETE, etc.) can invalidate the hostname once the API reports the deployment as nonexistent.
• Maintainer ericclemmons (MEMBER) is actively engaged. On 2026-08-11 he confirmed investigating ("may be a mismatch between deletion between Pages & the stored assets"), and on 2026-08-13 he posted a full independent reproduction with a step-by-step script, confirming a non-current deployment's hash hostname continues returning HTTP 200 with the old content after deletion. Whole-project deletion does stop the hostname.
• The issue is therefore confirmed, actively owned, and requires a fix on the Pages platform/edge side (deletion-propagation / asset cleanup gap). It should stay open as the tracking item.

Recommendation

Status: KEEP OPEN

Reasoning: This is a confirmed, reproducible bug — a maintainer has independently reproduced it and is actively investigating. The failing behavior is server-side Pages/edge asset-serving rather than a Wrangler CLI defect, so it cannot be closed and requires a platform-side fix plus likely platform-team escalation.

Action: No triage close needed — the issue is already owned and reproduced. Continue the in-progress investigation and escalate to the Cloudflare Pages platform/edge team to address the deletion-propagation gap between the control plane and the asset-serving edge.

Suggested Labels: product:pages, api (already applied)

Suggested Comment

Thanks for the detailed report — the reproduction steps and version info were really helpful, and we've since been able to reproduce this on our end. As you noted, the deletion itself works correctly on the Wrangler/API side (the deployment is gone from the listing and a repeat DELETE returns 8000009); the remaining behavior — the *.pages.dev hostname continuing to serve the deleted deployment's assets — is happening on the Cloudflare Pages edge/platform side rather than in Wrangler itself. We're escalating to the Pages platform team to close the gap between control-plane deletion and edge asset cleanup, and we'll follow up here with progress. In the meantime, deleting the whole project does take the hash hostname offline, if you need an immediate workaround for a sensitive deployment.

Structured summary (JSON)

{
  "issueNumber": 15083,
  "title": "Deleted Pages deployment hostname continues serving assets",
  "githubUrl": "https://github.com/cloudflare/cf-platform-issues/issues/67",
  "recommendation": "KEEP OPEN",
  "difficulty": "hard",
  "reasoning": "Confirmed, reproducible bug that a maintainer has independently reproduced and is actively investigating. The stale-hostname behavior is server-side Pages/edge asset-serving rather than a Wrangler CLI defect, so it must stay open pending a platform-side fix.",
  "suggestedAction": "Continue the in-progress investigation and escalate to the Cloudflare Pages platform/edge team to address the deletion-propagation gap between the control plane and the asset-serving edge.",
  "hasSuggestedComment": true,
  "suggestedLabels": ["product:pages", "api"]
}

[ericclemmons]

Investigating – initial research indicates this may be a mismatch between deletion between Pages & the stored assets, but working on reproducing the failure on our end.

[ericclemmons]

Reproduced this!

1. Create and enter a temporary directory:

REPRO_DIR="$(mktemp -d /tmp/pages-delete-repro.XXXXXX)"
cd "$REPRO_DIR"
pnpx wrangler auth activate personal

2. Create a unique Pages project:

PROJECT="pages-delete-repro-$(date +%Y%m%d-%H%M%S)"
pnpx wrangler pages project create "$PROJECT" --production-branch main
mkdir dist

3. Create advanced-mode deployment A:

printf 'export default { fetch() { return new Response("deployment-a"); } };\n' > dist/_worker.js
pnpx wrangler pages deploy dist --project-name "$PROJECT"

Record deployment A’s UUID and hash URL from the output.

4. Confirm deployment A works:

curl -i "https://<DEPLOYMENT-A-HASH>.$PROJECT.pages.dev/?nonce=$(date +%s)"

Expected body:

deployment-a

5. Create deployment B so A is no longer the latest deployment:

printf 'export default { fetch() { return new Response("deployment-b"); } };\n' > dist/_worker.js
pnpx wrangler pages deploy dist --project-name "$PROJECT"

6. Confirm both hash hostnames return their distinct content:

curl "https://<DEPLOYMENT-A-HASH>.$PROJECT.pages.dev/?nonce=$(date +%s)"
curl "https://<DEPLOYMENT-B-HASH>.$PROJECT.pages.dev/?nonce=$(date +%s)"

7. Delete deployment A:

pnpx wrangler pages deployment delete <DEPLOYMENT-A-UUID> \
  --project-name "$PROJECT"

Confirm the prompt when asked.

8. Verify deployment A disappeared from the control plane:

pnpx wrangler pages deployment list --project-name "$PROJECT"

9. Repeatedly request the deleted deployment with cache-busting query strings:

curl -i "https://<DEPLOYMENT-A-HASH>.$PROJECT.pages.dev/?nonce=$(date +%s)"

The bug is reproduced if this still returns HTTP 200 with deployment-a.

10. Optionally prove Funfetti considers it deleted:

pnpx wrangler pages deployment delete <DEPLOYMENT-A-UUID> \
  --project-name "$PROJECT"

Expected:

The deployment ID you have specified does not exist. [code: 8000009]

11. Clean up:

pnpx wrangler pages project delete "$PROJECT"

After whole-project deletion, the old hash hostname should stop serving, typically with HTTP 530/error 1016.