The build that succeeded at nothing

Deploys green. Site up. Content three days stale. Nothing errored, because nothing ran.

I spent an hour this week working out why a change to our landing page was not appearing on the live site. The commit was in main. Cloudflare showed a green tick. The site loaded fine. The change simply was not there.

The cause was one empty text field. The shape of the bug is worth writing down, because it belongs to a category most monitoring is blind to by construction.

What was actually happening

Our landing page is generated. A Python script reads a template and inlines the stylesheet and application source into a single file:

app-src/index.template.html  --+
app-src/styles.css           --+-->  build.py  -->  public/index.html
app-src/*.js                 --+

The template contains markers that the script substitutes. Nothing in app-src/ is served directly; it only reaches a browser if the build runs first.

In the project settings there are two fields, Build command and Deploy command. Ours read:

Build command:   None
Deploy command:  npx wrangler deploy

So every push cloned the repository, installed dependencies, skipped the build entirely, and deployed whatever public/index.html happened to be committed — a file baked on my laptop weeks earlier and never regenerated.

Why nothing complained

Uploading a repository as-is is a completely valid deployment. Every stage did exactly what it was asked: clone succeeded, install succeeded, deploy succeeded, the site responded with a 200. There was no failed step, no non-zero exit code, nothing for an alert to fire on. Uptime monitoring was green because the site was genuinely up.

The only thing wrong was that a step I believed existed was not in the list at all. An absent step produces no output to notice.

How it surfaced

Not through monitoring. I had added a line to the page footer and went looking for it. Had I not been hunting one specific visible string, this could have continued indefinitely, and every subsequent template change would silently have done nothing.

That is the compounding cost. A silent pipeline failure does not hide one change; it invalidates every conclusion you draw afterwards. Earlier that week I had spent time debugging why a data-fetching change had not taken effect. It had taken effect. It had just never been built.

The fix, and the check worth keeping

The fix was typing python3 build.py into the build command field. On the next deploy a Building stage appeared in the timeline that had never been there before, and the log printed the two lines the script emits.

The lesson is not "check your build command". It is that a green deployment is not evidence that your build ran. Those are different claims, and a deployment status only tests one of them.

• Assert on the artefact, not the exit code. A deploy succeeded only if the thing you expected to change actually changed. Grep the deployed page for a build timestamp or version string.
• Read the build log once after any config change. Not the status — the log. The stages listed are the ground truth about what ran. A missing stage is invisible in a summary and obvious in a log.

Why this matters more in automation

We build a scheduled automation tool, so this failure mode is one we think about a great deal. A flow that errors is easy: you see it, you get told, you fix it. A flow that runs and quietly does nothing useful looks identical to a healthy flow from the outside. That is a whole article of its own — see the flow that ran and did nothing.

It is why every run in Zymura stores the input and output of each step rather than a single pass or fail for the run. Run-level status tells you the flow completed. Only step-level detail tells you whether it did anything.

A green tick is a claim about whether something finished. It is never a claim about whether it was right.