Deploy Verification: Green Does Not Mean Live

A release process produces a lot of things that look like proof: a green CI run, a merged tag, a ticket field that says LIVE, a fix version stamped on a closed issue. None of those are the thing they claim to be, they're reports about the thing, and a report can be wrong without anyone lying. A workflow got deleted and every push kept showing a red failure from a run that no longer existed. A hotfix skill trusted git tags as the source of truth for version detection, and they weren't. A CDN cutover returned a clean 200 that turned out to be the old binding still answering underneath the one that was supposed to have replaced it.

These posts are grouped by where the false report showed up: in the release marker itself, in the deploy pipeline's own assumptions, in a JIRA field, in a branch that sat idle long enough to carry a stale flag into a release nobody re-checked. A few are about the guardrail that gets written only after the incident, a compile step nobody documented, a coordination cost that only became visible once several small fixes had to travel through the same release path independently.

The habit that runs through every fix: treat a status field as a hypothesis about the world, not the world. Then go check the world, the actual live file, the actual merged commit, the actual response body, before you call anything done.