A green health check is not a deploy — grep the bundle

A deploy reported success. The health check was green. The feature was not there.

This has happened to us more than once across a dozen products, and it is one of the most disorienting bugs to chase, because every signal you normally trust is lying to you. The pipeline says deployed. The container is healthy. The site loads. And the change you just shipped is simply absent.

Here is why it happens and the one habit that catches it every time.

Why a green deploy can ship nothing

A deploy is a chain: build the artifact, move it to the server, restart the thing that serves it. A successful deploy only means the chain did not error — not that the new code is now serving traffic. The gap shows up in a few predictable ways:

In every one of these, the health check passes because it only asks "are you up?" — not "are you the version I just built?"

The habit: grep the live bundle for a string you just shipped

After every deploy, fetch the actual production asset and search it for a string that only exists in the change you just made. A new button label. A new route. A new constant. If the string is there, the new code is live. If it is not, the deploy lied, and you know it in ten seconds instead of after a confused customer email.

The discipline sounds trivial. It is the single highest-leverage ten seconds in our deploy process.

The minified-name gotcha

One refinement we learned the expensive way: grep for string literals, not function or variable names.

Production bundlers minify. A function named handleCheckoutSubmit becomes a single letter. A component named AlarmPanel becomes something unrecognizable. If you grep the production bundle for the function name, you will not find it — and you will wrongly conclude the deploy failed when it actually succeeded.

But string literals survive minification. A user-facing label, a color hex, an object key that gets serialized, a URL path — those are still in the bundle verbatim. So pick your grep target deliberately: the new UI text you added, not the function that renders it. We once burned real time "confirming" a deploy had failed because we grepped for a function name that had been minified away. The feature was live the whole time.

What this looks like in practice

For a static site, fetch the page and its referenced script chunks and grep across them. For an API, hit the new endpoint and assert the new shape. For a server-rendered app, request the page and grep the HTML for the new literal. The mechanism varies; the principle does not — assert the new thing exists in what production is actually serving, using a token that survives the build.

What I would tell another team

We ship from a small team across a lot of surfaces. "Verify the artifact, not the pipeline" is one of the handful of habits that lets us move fast without shipping ghosts.

If you want a team that treats "it deployed" as a hypothesis to test rather than a fact to trust, [say hello](https://bluewaveprojects.com/booking).

More from BlueWave