The misleading green check
One of the most dangerous deployment failures is the one that looks healthy. The homepage returns HTTP 200, the application starts, and a smoke test that checks only the root URL passes. Meanwhile, the browser is requesting stylesheets, scripts, fonts, and images that now return 404.
That is exactly what can happen when a domain moves to a different backend. The application is alive, but the static asset directory did not move with it—or the new web server has no rule that maps the asset URL to the files on disk.
Why the homepage still works
Dynamic routes and static files often take different paths through a deployment. A reverse proxy may send / to the application process while expecting nginx or another web server to serve assets directly. If the new origin knows about the application but not its wwwroot/s/ directory, the HTML renders and every dependent asset quietly fails.
In one incident, 66 static files returned 404 while the homepage remained a healthy 200. Users saw an unstyled or partially interactive page; monitoring saw a green endpoint.
What to check after a cutover
- Test representative assets, not just the homepage. Check a CSS file, JavaScript bundle, font, and image from the deployed release.
- Compare the origin and public paths. Confirm that the files exist on the active backend and that the proxy forwards their URL prefix correctly.
- Inspect response headers. A 404 from the application, a 404 from nginx, and a Cloudflare cache hit point to different fixes.
- Test with a cache miss. A stale edge response can hide whether the origin is fixed.
Make asset health part of deployment health
Add a small asset smoke test to every release. Fetch known files over the real HTTPS hostname, validate the certificate, assert a 200 response, and verify the content type. Keep the checks versioned with the application so they change when the asset pipeline changes.
Also make the serving contract explicit: document which process owns static files, where the directory lives, and which URL prefixes must be routed to it. A backend cutover should be considered incomplete until that contract is verified.
The takeaway
A 200 on the homepage proves only that one route works. Reliable deployments test the resources that make the page usable. When static assets are treated as first-class production dependencies, a healthy-looking homepage can no longer hide a broken release.