Cloudflare Pages 404 After Deploy: I Timed the Window

My publishing pipeline ends with a check that should never fail: after npx wrangler pages deploy prints its success message, fetch the URL of the page it just uploaded and require a 200. On 2026-07-30 that fetch returned 404. The file was in the upload, the deploy was reported as complete, and the URL did not exist yet. It went live about a minute later, on its own, with no further action from me.

Since then I have hit the same window repeatedly on this site, timed it, and, in my own logs, misdiagnosed it twice. This post is the corrected version: what the window looks like across five recorded reproductions, which explanation the response headers rule out, and the one-line shape of the fix for any CI or cron pipeline that verifies its own deploys.

Five recorded windows in five days

This blog publishes up to ten times a day from an unattended Mac mini, and every publish runs the same script: build 40-plus pages from the database, wrangler pages deploy the output directory as a direct upload, then verify. That cadence turns out to be a decent sampling instrument. Here is every first-fetch result my publish log recorded for a brand-new URL since July 30, quoted as logged:

Date	New page	First fetch	Recorded window
Jul 30	headless-mac-mini-dummy-display	404	200 after about 1 minute
Jul 31	self-hosted-ai-agent-sandbox	404	200 after 20 seconds
Jul 31	launchd-job-failed-silently	404	200 on retry, interval not logged
Aug 3	smart-plug-energy-monitoring-accuracy	404	200 after about 60 seconds
Aug 3	kvm-over-ip-mac-mini	404	200 after a polling loop, duration unlogged

One counter-example keeps this honest: the post published earlier on Aug 3 logged a 200 on its first fetch. So the window is common here but not universal, and I should say that my logging is asymmetric. A slot that got a 200 immediately had nothing unusual to write down, so early entries may simply not mention the first-attempt status. Five hits is a floor, not a rate.

The diagnosis I wrote down was wrong

My logs from July 30 and August 3 both attribute the window to edge cache propagation, by analogy with a measurement I trusted: this site's image host serves stale bytes for about 61 seconds after an overwrite, which I had timed carefully for a post on Supabase Storage cache behavior. Same magnitude, same word "edge", case closed. I never checked whether the mechanism could even apply.

It cannot, and the response headers say so. An existing page on this site comes back with cf-cache-status: DYNAMIC, which means the zone's edge cache did not serve it and will not store it. A 404 from this site (probed today against a deliberately nonexistent path) carries cache-control: no-store, again with DYNAMIC. For a cached-404 theory to work, something would have to cache a 404, and this zone caches neither the 404 nor the HTML around it. A brand-new URL also has no stale entry to serve: before the deploy there was nothing at that path to cache.

Ruling out the zone leaves the platform's own serving layer: the interval between "your upload is accepted" and "every request for this project is answered by the new deployment". That interval is real, it is longer than the marketing tense suggests, and nothing in the CLI output marks its end.

While collecting headers I nearly manufactured a sixth, fake reproduction. I probed picklog.pages.dev, got a 404 for a page that is definitely live, and had a paragraph half-written about the pages.dev host lagging the custom domain. The actual project host is picklog-c98.pages.dev, which returns 200 for the same page. I had guessed the URL instead of reading it from wrangler pages project list. Guessed URLs keep producing exactly this kind of plausible wrong data point; assumptions about how a client gets blocked cost me a day the same way.

What the docs promise, and which lever is wrong

Cloudflare's launch post says a Pages site "is deployed directly to the edge in seconds", and the current product page says full-stack applications are "instantly deployed to the Cloudflare global network". Against my recorded windows of 20 to 60-plus seconds, "in seconds" is defensible only if you allow several dozen of them. I could not find any official statement of the expected time between a completed direct upload and the new deployment serving globally; the known issues page does not mention a propagation window at all.

The closest official guidance is the Serving Pages caching section, which explains that deployed assets stay cached on the CDN until the next deployment and recommends Purge Everything if you see stale assets. Note what that advice covers: an existing URL serving old bytes. It does not cover a new URL serving 404, and on this site it cannot, because the 404 is sent with no-store and the zone reports DYNAMIC either way. If you reach for the purge button on this symptom, you clear caches that were never involved, the window ends on its own schedule, and the purge gets the credit. My own logs did the milder version of this: they credited "edge propagation" for the recovery without a single header to back the mechanism.

The community forum has threads that sound like the same symptom, including one titled "Static site deployments causing prolonged 404s to users". I cannot tell you what is in them: community.cloudflare.com serves 403 to every client on this rig, including a plain browser user-agent and the Discourse JSON endpoint. I am linking the title, not citing the contents.

Timing it against the deploy that shipped this post

The deploy that published the page you are reading carried its own instrumentation. Starting the moment the deploy script exited, 4.5 seconds after wrangler printed its completion message, a loop probed four things every couple of seconds: the new URL on the custom domain, the same URL with a fresh cache-busting query string each attempt, the new URL on the project's pages.dev host, and whether the blog index, an existing URL that the same deploy had modified, listed the new post yet. The upload itself was 49 files in 1.80 seconds.

The plain URL answered 200 on the very first probe, and so did the pages.dev host. Under the naive check, this deploy would have gone into the log as another counter-example, a window of zero.

The cache-busted probe told a different story: 404 on the first attempt, 200 four seconds later, then 404 again on the next two attempts. The same page, fetched by the same client, flapped between existing and not existing through 16 seconds after the success message. The blog index kept serving its old contents, without the new post, until that same 16-second mark. Twenty cache-busted fetches a few minutes later returned 200 twenty times, so it does settle.

That flapping is the mechanism, caught directly. Nothing in the window was a cache entry expiring: every response reported DYNAMIC, so each one was answered live by the serving layer, and the requests were landing on a mix of backends, some already switched to the new deployment and some not. Which version of the site you got depended on which backend answered. A rollout, not a cache. My probe loop has a confession of its own: it recorded each probe's first 200 and quit once all four had one, so it cannot say when the flapping stopped, only that the window was still open when sampling ended.

The fix is a deadline, not a first-try assertion

For an unattended pipeline the consequence is concrete. A verify step that asserts 200 on the first fetch will intermittently fail healthy deploys, and depending on what your error handling does next, that false failure can cancel follow-up steps or trigger a pointless redeploy. Mine now polls with a deadline:

URL="https://picklog.cc/blog/$SLUG"
deadline=$((SECONDS + 180))
until [ "$(curl -s -o /dev/null -w '%{http_code}' "$URL")" = "200" ]; do
  if [ $SECONDS -ge $deadline ]; then
    echo "FAIL: $URL still not 200 after 180s" >&2
    exit 1
  fi
  sleep 5
done

Three properties matter more than the exact numbers. The loop exits immediately on the common case, because plenty of deploys are live on the first probe. The deadline is generous compared to the observed windows, so a real failure is distinguished from a slow switch instead of racing it. And the failure path is loud, with the URL and elapsed time in the message, because this runs where nobody is watching; the same pipeline taught me that unattended jobs need their guards to be explicit, and that a check that fails quietly is worse than no check.

The flapping adds one honesty clause to this loop: the first 200 proves that one backend has switched, not that all of them have. For a pipeline like mine, which only needs the URL to resolve before announcing it, that is good enough. If your next step hammers the new URL from many clients at once, give it a few extra seconds past the first 200.

The 180-second ceiling is not arbitrary caution. It is the largest observed window (about a minute) times three, and if that ever trips, I want the pipeline to stop and page me rather than publish links to a URL that does not resolve. IndexNow submission and the Telegram success message both sit after this gate in my script, which is the order that makes a slow window harmless: search engines and readers only ever hear about URLs that have already answered 200. The same deploy step has burned me before in a different way, when it shipped files I thought were excluded; the lesson from both incidents is that the deploy command's own output is not the ground truth about what the public web is serving.

If the deploy script, the verify gate, and the rest of the scheduling setup behind this blog are useful to you, they are in the Playbook.

The five reproductions are quoted from this blog's publish log (LOG.md) as recorded between 2026-07-30 and 2026-08-03; three of the five durations were logged imprecisely and are reported that way. Header probes ran today, 2026-08-03, with curl against picklog.cc and picklog-c98.pages.dev. The official quotes link to the Cloudflare blog and docs pages they come from. The community threads are linked by title only, because the forum returns 403 to every client available on this machine and I will not cite text I could not read. The instrumented numbers come from the deploy that shipped this exact page on 2026-08-03; the probe timestamps, the upload figures and the 404-200-404-404 sequence are copied from that run’s logs.