A successful build and rollout can leave the original bug unfixed. The build checks that an image can be produced; the rollout checks that the service meets its readiness conditions. Neither necessarily exercises the user flow that failed.
To verify a fix, first confirm which image is running, then repeat the affected action under the conditions that caused the bug.
Identify the artifact before the behavior
First, confirm what you deployed. For an image built in external CI, follow the source commit to the exact image digest and the deployment that references it. If the application has an API, worker and setup job, inspect the services involved in the change.
Hakopod’s CI provenance can retain that relationship, but an accepted claim is not the same as a runtime observation. Check current image IDs and readiness instead of stopping at the release metadata.
A moving branch or tag can make a quick glance misleading. Use immutable identifiers when you need to decide whether a particular fix is present.
Check the behavior that changed
A readiness endpoint might confirm that the process started and can accept traffic. It may intentionally avoid querying every dependency or running expensive business logic.
That is sensible for routing. It means you still need another check for the behavior you changed. If the bug involved a queued job, opening the home page does not exercise it. If it depended on a particular account state, an anonymous request may miss it entirely.
Choose a targeted replay or a safe application-level check that reproduces the relevant conditions. Record the expected outcome before running it, so a different response does not become “close enough” after the fact.
Use operational views to explain the result
Requests can show a completed HTTP call through managed ingress, along with its status, timing and backend. Logs and pod events can explain what happened inside the workload. The current routing view helps confirm where traffic can go now.
Each view has limits. Internal service calls are outside Requests, a historical backend differs from a current endpoint, and short retention windows can lose old evidence. Gather the relevant facts while the investigation is still fresh.
A deployment notification is helpful here as a marker: the rollout reached a result at a particular time. It is not a substitute for checking the original issue.
When you report completion, say what passed: build, rollout, runtime identity and the targeted behavior. If one is missing, keep it visible. That tells the next person which checks still need to run.
Read deployment behavior, CI provenance and Requests for the evidence available in Hakopod.