Deployment state tells you what changed. Runtime evidence tells you what is working.
There is more than one kind of success
A build can pass while an image contains a startup error. A container can start while its database connection fails. A health endpoint can return success while a critical user workflow is broken. Each signal answers a different question.
Start verification with a concrete operation: request a page, submit a safe test input, or read a known record. Compare the expected behavior with the response and relevant logs. A dashboard is useful context, but it does not replace checking the actual path your users depend on.
Review the change before applying it
Know which image, configuration, secrets, ports, and resources change. Identify any database migration or external effect that will be difficult to reverse. Review capacity for the rollout, not only the steady state.
Keep the change small enough to understand. If you alter code, network policy, and data shape at once, a failure becomes harder to isolate. Preserve the previous working artifacts and the evidence needed to identify them.
Rollback has a boundary
A configuration rollback creates a new deployment using an earlier definition. It does not turn back time. The earlier image still needs to exist; current credentials and permissions still need to work; and the old code must understand the current database state.
For a data migration, plan compatibility and recovery before rollout. A forward repair may be safer than restarting old code against a changed schema. Treat that as an explicit decision, not an assumption hidden behind the word rollback.
In Hakopod
Review deployment history and immutable application revisions, then inspect services, pods, logs, Requests, and resource probes. CI provenance connects a reported source commit and image digest to a release; it is not proof that every running pod has already updated.
Alarms help direct attention. An alarm’s absence is not a complete health assessment, especially if a rule or delivery channel has not been configured.
Build a short verification record
Write down what changed, what is currently running, which request you checked, and what the response showed. Include a timestamp and the relevant identifiers. Those details make the next investigation more useful than “it worked when I deployed it.”
All containers are ready. Is the checkout or signup workflow necessarily healthy?
Reveal the answer
No. Readiness is one signal. Verify the actual workflow and its dependencies with a safe test, then inspect the response and relevant runtime evidence.