If a deployment job ends after updating the GitOps repository, it proves the desired state has been written, but not that new documentation is already available on the site.
A Merge Request with mandatory checks can separate preparation from publication for Flux. That boundary is discussed in “Why CI in a GitOps Repository Is Not a Deployment Gate”. But a successful merge still does not answer a different question: which version is a reader receiving right now?
Here I am looking at documentation publication as a whole, not only at updating a Kubernetes Deployment. Handing a change to the next component is not enough. The result needs its own proof.
Each status proves a different boundary
A commit in the watched branch means the change became available to Flux. Successful reconciliation proves that configuration was applied and that the configured checks passed. Flux can wait for resource readiness through healthChecks or wait, so its success should not be reduced to “the manifests were sent.”1
A completed rollout means Kubernetes updated the replicas and satisfied its availability conditions. But the status of a Deployment alone does not prove that a request to the site goes through the expected route and returns the expected documentation.2
These statuses are useful for diagnosis. The problem starts when one of them is treated as proof of the entire publication.
HTTP 200 can come from the previous version
Suppose the update has not reached the application yet, while the previous version is still healthy. A request to the site returns HTTP 200. An availability check passes even though the result of the current release is not there.
So confirming publication requires more than proving that the site responds. The check needs to distinguish the expected version from every other working version.
One approach is to poll the site and wait for the expected revision. A successful HTTP response is only the first condition. The check then reads the response body and compares the published identifier with the expected full revision.
The contract is simple:
the site responds successfully
+
the published revision matches the expected revision
The previous version can no longer serve as evidence for the current release, even if it is perfectly healthy.
The expected revision must be known before the request
In this example, the comparison uses the full source revision identifier rather than only a human-readable release number or a short SHA. The check must know which revision the current pipeline is publishing and look for exactly that value.
The expected value must also be independent from the observed value. If the check first reads the version from the site and then declares that value expected, any already published state will pass.
The metadata has to come from the build that the application is actually serving. Writing a new revision to some separate storage does not prove that the site itself changed.
In this case, the revision is not decorative version text. It ties a particular release to an observable application response.
Wait for a condition, not a fixed delay
GitOps delivery is asynchronous. After a change enters that process, the required version may not appear immediately. The publication check therefore repeats requests until it sees the expected revision or exhausts the allowed time.
A fixed sleep would prove something else: only that a certain number of seconds passed. With fast delivery it wastes time; with slow delivery it checks too early.
Waiting needs two boundaries: a timeout for an individual request and an overall deadline for publication. A stuck connection should not consume the whole window, and polling should not continue forever.
Reaching the deadline means “publication was not confirmed within the allotted time.” It does not prove that publication can never happen. The observer may stop waiting while the rest of the system continues working. A timeout alone is also not enough to infer that a rollback is required.
What this check actually proves
A response containing the expected revision proves that this revision became available at the checked address from the point where the request was made. It is a publication check, not proof that the entire system is healthy.
One request may hit an already updated replica while other replicas are still rolling out. A revision check therefore does not replace rollout observation. It also does not test every page, browser behavior, or reachability from every user network.
The important addition is exactly this HTTP-level proof of the expected revision. Handing off a change and making the release result available become two separate observable conditions.
That is where the publication check can end. Ongoing availability belongs to continuous monitoring, not to a pipeline that waits forever.