The build is green. The deployment is green. The original bug is still there.
There does not have to be a contradiction. The build checked that an artifact could be produced. The rollout checked its own readiness conditions. Neither necessarily exercised the user flow that failed.
A useful release process gives those checks distinct jobs so the final decision rests on evidence that matches the problem.
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.
Ask a question the readiness check can answer
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 makes the report more useful to the next person than a single undifferentiated “done.”
Read deployment behavior, CI provenance and Requests for the evidence available in Hakopod.