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. Use the dashboard to investigate failures, and check the workflow your users depend on directly.
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. Check that there is enough capacity during the rollout, when old and new containers may overlap.
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.
Check whether rollback is safe
A configuration rollback creates a new deployment using an earlier definition. 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. Decide which recovery path is safe before starting the migration.
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 give the next investigation a record of what you checked.
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.