The Dashboard Said Deployed. The Domain Said Nothing.

Every push to my portfolio site came back green. Build passed, deployment successful, little checkmark, preview link. I shipped to it over and over without a second thought.

Then a widget demo refused to load. The widget lives on a subdomain of my own site, and the embed just died. No error, no response, nothing. That read like a wrong address, so I checked from outside. Not my dev setup and not the preview link. A plain curl at the subdomain from a machine that had never touched the project.

The name did not resolve.

Then I checked the apex. My actual domain. The one printed on everything.

Also nothing.

Cloudflare Pages gives every project a pages.dev address, and every deploy lands there automatically. Attaching your real domain is a separate step in the project settings. Do it and DNS records get created and traffic flows to your name. Skip it and everything still works from the preview address, forever, without a single warning. I had skipped it. Maybe I attached the domain on an older version of the project and never redid it after a rebuild. I could not tell you. Nothing ever told me it was broken, so I cannot tell you how long it was broken.

The reason this failure mode stays invisible is that your own machine lies to you. You browse your site through the preview link because that is what the dashboard hands you. Your browser autocompletes the address you have used a hundred times. Every path you personally take works, so the site feels live. The only person who experiences the truth is a stranger typing your domain into their phone, and strangers do not file bug reports. They just leave.

The fix took about two minutes. Attach the custom domain in the Pages project and add CNAME records for the apex and www pointing at the pages.dev target. The widget subdomain needed its own attachment to the worker that serves it. Then wait for propagation. Two minutes to fix. No idea how long it sat broken.

“Deployment successful” turned out to mean something narrower than I was reading into it. It means your files made it onto the host’s network. It says nothing about whether your domain points at them. Two different claims. The dashboard only ever made the first one, and I kept hearing the second.

What changed afterward is the part worth writing down. The last step of every ship is now an outside-in check: hit the real domain from something that is not my machine. My phone on cell data works fine. So does a curl from a clean box. If the page answers from there, it is live. If it only answers from the preview link, it is not live, whatever the checkmark says.

I made the habit structural so I could not skip it. My coding agent ends every deploy prompt with a verification block: curl the production URL and grep for the thing that just changed. The run does not count as done until production answers from the outside. Set up that way, this hole would have been caught on day one instead of whenever I finally stumbled into it.

Dashboards report on themselves. The host knows its network is holding your files. It does not know whether a stranger typing your domain gets your site, and only checking from the stranger’s side answers that question.

If you shipped something recently, curl it from outside right now. It costs ten seconds. I skipped it for a long stretch of deploys and still do not know what the skip cost me.