A green deploy is not a working site
August 1, 2026
On a Thursday morning I opened my own site’s sitemap for an unrelated reason and found that fifteen case-study pages — every single one — were returning a server error. Thirty-seven of fifty-two pages were fine. Twenty-nine percent of the site was down. The build was green. The deployment said “Ready.” Nothing had alerted anyone, and I have no idea how long it had been that way.
Everything that was supposed to catch it, didn’t
This is the uncomfortable part. Type checking passed, because the types were valid. Linting passed. The build exited cleanly. The hosting platform reported a successful deployment and showed a green check. Every gate a normal team relies on said the release was good, and every one of them was answering a different question than the one that mattered.
Those tools all inspect the code before it runs. The failure only existed when a real browser asked for a real page — a caching decision that behaved one way at build time and another way at request time. There is no amount of static analysis that finds that. The only evidence is an actual request against an actual server.
Why nobody noticed
The homepage was fine. Navigation was fine. Anyone clicking around casually would have seen a perfectly healthy site. The broken pages were the deep ones — the individual case studies — and four of them weren’t linked from anywhere on the site at all. They existed only in the sitemap, which is to say they existed only for search engines and for anyone arriving from a link someone had shared.
That’s the quiet version of an outage, and it’s the expensive one. Your traffic still arrives. Your ads still spend. The pages people land on are the ones that fail. And because your analytics only record visits that succeed, the dashboard looks calmer than usual rather than alarming.
The check that runs now
The fix for the bug itself was one line. The fix for the class of problem was a habit: after every deploy, walk the sitemap and issue a real request to every URL on it. If a page is listed in your sitemap, you have publicly promised to serve it — so that list, not the link graph, is the contract worth testing.
- Sweep every sitemap URL after each deploy, not just the homepage.
- Fail loudly if the sweep finds fewer pages than expected — a check that can pass over an empty list is worse than no check.
- Run two independent checkers; agreement between them is far stronger evidence than either alone.
- Treat a red build alert you’ve stopped reading as no alert at all. Mine sat red for four days for a billing reason and looked identical to a genuine failure.
What this means if you’re the one paying for the site
You do not need to understand caching semantics. You need one question answered honestly by whoever builds and hosts your site: after you deploy, does anything actually request the pages? Not “did the build pass” — did something load them, the way a customer would.
If the answer is no, then your monitoring is your customers, and they don’t file reports. They just leave, and you find out weeks later in a search ranking you can’t explain.
The takeaway
Green builds and successful deployments only prove that code compiled and files shipped. Sweep every URL in your sitemap after every release — a real request against a real server is the only thing that proves your pages render.
Capabilities this touches