← Writing

Cloudflare Pages can show you a stale build — check the deployment before debugging your code

After a deploy, the page you're looking at may still be a cached previous build — verify which deployment is actually serving before concluding your change didn't work.

While iterating on an admin app deployed to Cloudflare Pages, I hit the most demoralizing failure mode in web development: push a fix, reload, and see the old behavior. I started debugging the fix. The fix was fine — the browser was showing me a cached previous build.

Between Cloudflare’s edge cache and the browser’s own cache, “I deployed” and “I am looking at the deploy” are separate claims, and the second one needs verifying. What I do now before touching the code again:

  • Check the deployment list first. The Pages dashboard shows whether the new build actually succeeded and finished — a build that failed or is still running means there’s nothing new to see yet.
  • Load the unique deployment URL. Every Pages deployment gets its own <hash>.<project>.pages.dev URL that can’t be confused with a cached production alias. If the change is visible there but not on the main domain, it’s a caching problem, not a code problem.
  • Hard-reload / bypass the browser cache before drawing any conclusion from the production URL.
  • Put something verifiable in each build — even temporarily logging a build timestamp or commit hash — so “which build am I looking at?” has a factual answer instead of a vibe.

The habit generalizes beyond Pages: any time a deploy “didn’t work,” the first question is never “what’s wrong with my change?” It’s “am I actually looking at my change?” The second question is only allowed after the first has a proven yes.

← All writing Book a call →
Book a call → WhatsApp