Verify after propagation, not after push
A redirect was reported broken seconds after pushing. It simply was not live yet. How we check deploys now.
PaceStreak’s website has a short redirect, /twitter, that points at the
project’s profile. After a push that added it, the redirect was checked
straight away, did not work, and was reported as broken.
It was not broken. It was not deployed yet.
How deploys work here
Pushing to main deploys. The website and the blog are Git-connected
Cloudflare Pages projects: a push triggers a build on Cloudflare, the build
runs npm ci and the site’s build, and the result is published to the edge.
There is no deploy workflow of our own and no API token in either repository.
That pipeline takes time: a queue, an install, a build, and then propagation
across the edge. Checking a URL seconds after git push tests the previous
deployment.
How we check now
Deployment history is readable without a token:
npx wrangler pages deployment list --project-name=pacestreakThe workflow is:
- Push.
- Watch the deployment list until the new commit appears and has finished.
- Then request the URL, bypassing any local cache.
Only a failure at step three is a bug.
A related trap: the edge cache
Even after a deploy, some files can be served stale from Cloudflare’s cache. The available API token can only read the zone, not purge it, so a purge is a dashboard job. That is a known outstanding task, and it is another reason to confirm what the edge is actually serving before drawing conclusions.
The lesson
“It doesn’t work” and “it isn’t there yet” produce the same response. Tell them apart before reporting either.
AlzyWelzy
Building PaceStreak. GitHub
Related
InfrastructureWhat the free tier actually buys, checked against the account
The API runs on a GCP e2-micro because that's what Always Free covers - one instance, 30 GB of standard disk, an ephemeral IP. It turns out to be sitting exactly at that ceiling, which explains more of the outage two posts back than any single bug did.
3 min
InfrastructureOne outage, four root causes
The API went down behind a Cloudflare Tunnel error and stayed down through a reboot, an interrupted OS upgrade, a stale connection pool, and a box too small for its own workload. None of the four were the same bug.
9 min
InfrastructureA status page that watches the whole stack, finally
app and api had no DNS records for most of their existence, so there was nothing to monitor - which meant status.pacestreak.com kept quietly not telling the whole story even after both went live. Fixed, plus a lesson in why a 200 from the app proves nothing about the API behind it.
2 min