The dangerous version of “healthy”
A homepage returning HTTP 200 is reassuring—but it is not proof that the site is healthy. During a backend cutover, our homepage stayed available while 66 files under wwwroot/s/ began returning 404.
That failure mode is easy to miss because the HTML still renders. Visitors see a page that looks mostly intact, while missing styles, scripts, fonts, or images quietly degrade the experience and can break key interactions.
Why the assets disappeared
Application-served static files do not automatically follow a domain move. Our wwwroot/s/ files were served by the app, not by an nginx location block. Moving the domain to a different backend silently dropped them: the vhost could serve the homepage, but the new origin did not have the asset path wired correctly.
The release checks we use now
- Verify TLS and the site-specific homepage marker, not just a status code.
- Probe a representative set of CSS, JavaScript, font, and image URLs under
/s/. - Check the origin after a cutover before relying on Cloudflare cache.
- Purge the zone after a fix, then confirm the public request is a cache MISS.
- Keep an asset manifest and compare it across backends.
Health means the page and its dependencies
The lesson is simple: synthetic monitoring must test what users depend on, not only the document root. A green homepage check can coexist with a broken frontend. Treat static assets as first-class release artifacts, verify them at the origin and edge, and a backend cutover becomes a controlled change instead of a hidden regression.