The pipeline is green. The container is running. A customer still cannot complete a request. These statements can all be true because each measures a different part of the delivery process.
For a team operating a small application, this distinction matters more than the color of a dashboard. A successful release should produce a service that does the job it was deployed to do, with enough evidence for someone else to verify that conclusion.
Define four separate checks
A build check asks whether the code can be packaged. A process check asks whether the container is alive. A readiness check asks whether it should receive traffic. An application check asks whether a representative operation succeeds. Avoid using one vague health endpoint as proof of all four.
In Kubernetes, readiness and liveness probes serve different purposes: readiness affects whether a container is ready for traffic, while liveness failures can trigger restarts. Startup probes can protect slow initialization. Probe behavior needs to match the application rather than being copied from another service.
Choose a useful smoke test
For a read-only API, a smoke test could retrieve a known test record through the public routing path and validate the expected response. For a write operation, use an isolated test tenant and a cleanup procedure. Do not create real orders or send customer messages simply to prove that a deployment succeeded.
Suppose an API process starts even though its database credentials are incorrect. A process check passes, but a representative request fails. That synthetic example shows why checking the running process alone leaves an important blind spot.
Do not turn a dependency outage into a restart storm
If every temporary downstream failure causes the application to fail its liveness check, repeated restarts can make diagnosis harder. Decide which conditions require restarting the process and which require removing it from traffic or returning a controlled error. There is no universal probe configuration for every workload.
Make the result actionable
Capture the application version, environment, time, endpoint tested, and sanitized failure details. A failed verification should produce an explicit outcome: stop promotion, recover using the agreed procedure, or request human review. It should not quietly continue because the deployment stage itself succeeded.
A practical release checklist is: expected version, bounded startup time, representative smoke test, routing verification, useful logs, and a recovery owner. Review it after a real failure to see which assumption the checks missed.
I work across deployment automation and infrastructure troubleshooting. If your team has a green pipeline but uncertain releases, we can start with a review of the deployment checks and define the missing evidence.