Before deploymentci-cd-post-deploy

Post-Deployment Validation Checklist

16 items ·9 critical ·4 warn ·3 info

How to use this checklist

This is the gate a deploy must pass before the change ticket is closed. It is not “the deploy command returned success” — it is the user-visible and observable state after the deploy.

Work it through immediately after rollout completes, while the evidence is still warm. A deploy that passes the rollout but fails this checklist is a deploy that needs to be rolled back or remediated, not declared done.

Sign-off

Every critical item must pass. A failing critical item blocks the change from being closed and may trigger a rollback; it is not a note for later. Record the date, the reviewer, and the disposition of every item that did not pass.

Critical9 items

The rollout has reached 100% of replicas, the old replicas have been terminated, and no pod is stuck in `Terminating` or `Pending`. A rollout that hangs is treated as a deployment failure, not as a slow start.
```
kubectl rollout status deploy/&lt;name&gt; --timeout=10m; kubectl get pods -l app=&lt;name&gt; -o wide
```
For GitOps environments, the application is `Synced` and `Healthy` in Argo CD / Flux. `Degraded`, `Suspended`, or `Progressing` past the timeout is a failure state, not a transient one.
```
argocd app get &lt;app&gt;; flux get kustomization &lt;name&gt;
```
Liveness, readiness, and startup probes are passing for every replica. A probe that fails for more than the configured threshold has triggered a restart loop, which is the canary for a broken deploy.
```
kubectl get pods -l app=&lt;name&gt; -o json | jq -r '.items[] | "\(.metadata.name) ready=\(.status.containerStatuses[]?.ready)"'
```
Smoke tests have been executed against the deployed service (synthetic request, API health endpoint, login, sample query) and the result is green. A failed smoke test is an immediate rollback trigger.
The 5-minute and 1-hour error rate is within the baseline established before the deploy. A deploy that pushes error rate up by more than the agreed budget is rolled back, not "watched for ten more minutes".
```
curl -s http://prometheus/api/v1/query?query=rate\(http_requests_total\{job="&lt;service&gt;",status=~"5.."\}\[5m\]\)
```
Downstream dependencies the service relies on (database, cache, message queue, upstream APIs) are healthy and have not registered an alert since the deploy.
The change ticket is updated with the deploy timestamp, the artifact digest, the pipeline run URL, the deployer, and the validation result. The ticket moves to `deployed` only after this entry exists.
For GitOps, `argocd app diff` / `flux diff` is empty against the new commit. The repo, the cluster, and the controller now agree.
```
argocd app diff &lt;app&gt;; flux diff kustomization &lt;name&gt;
```
A user-visible behaviour check has been performed (synthetic transaction, real user signal, support inbox). A green service mesh metric with a broken user flow is still a broken deploy.

Warning4 items

p50 / p95 / p99 latency is within the baseline established before the deploy. Latency regressions are a deploy-quality finding and a possible rollback trigger.
No warning-level log volume has spiked compared to the baseline. A 10x increase in warning logs is a smoking gun for a config or schema bug introduced by the deploy.
Feature flags are in the intended state for the deploy: flags that were supposed to flip are flipped, flags that were supposed to stay off are off. A flag that ended up in the wrong state is a finding.
On-call has been notified that the deploy is complete and validated. The change ticket carries the contact path if anything regresses in the next 24 hours.

Info3 items

A snapshot (URL or screenshot) of the primary service dashboard at +5 and +15 minutes after the deploy is linked from the change ticket. "It looks fine" is not the snapshot.
Old pods, old container images on nodes, old replicas, old Terraform state versions, and any leftover debug resources from the deploy have been cleaned up. The next deploy should not inherit leftovers from this one.
A deploy is a candidate for a post-mortem if it caused an alert, a rollback, or a user-visible regression. The trigger is filed before the change ticket is closed, not in the post-incident review a month later.