In the first version of delivery for my DocOps project, the deployment job ended after updating the GitOps repository. That proved the desired state had been written, but not that the new documentation was already available on the site.
Later, a Merge Request with mandatory checks appeared between preparing the change and publishing it for Flux. I described that boundary in “Why CI in a GitOps Repository Is Not a Deployment Gate”. But a successful merge still did 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.
In my DocOps flow, a post-deploy check polls the site and waits 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
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.
For my use case, the important addition was exactly this HTTP-level proof of the expected revision. Previously the process reported that a change had been handed off. Now it has a separate observable condition: the site serves the result of the expected release.
That is where the publication check can end. Ongoing availability belongs to continuous monitoring, not to a pipeline that waits forever.