deploy-verify-loop

name	deploy-verify-loop
description	Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand.
disable-model-invocation	true

Deploy-verify loop

A deploy that reports success isn't the same as a deploy that's actually healthy — a rollout can finish while a pod crash-loops, a health check flakes, or the new version 400s on a path the deploy step never exercised. This loop watches the window right after a deploy closes and turns "did it work?" into a checked answer instead of a hope.

Step 1 — Establish what "rolled out" means here

Before polling, confirm the concrete signal for this deploy target — it varies by platform:

• Kubernetes: every replica of the relevant Deployment(s)/StatefulSet(s) on the new image digest/tag, Ready, no CrashLoopBackOff.
• A PaaS/serverless platform: the release/deployment resource's own status field reaches its terminal "active"/"succeeded" state.
• A generic host: the running process's version endpoint (or build hash) matches what you just shipped.

Done when you can name the exact check that proves the rollout finished — not "give it a few minutes."

Step 2 — Poll with a bound, not indefinitely

Check the Step 1 signal on an interval matched to how fast this deploy actually rolls (a Kubernetes rollout finishes in seconds to minutes; a CDN/edge propagation can take longer — don't poll a slow system every few seconds). Set a hard timeout. If the timeout is reached before the signal clears, stop and report exactly what's still not ready — don't keep polling past the bound hoping it resolves.

Step 3 — Check for the failure the rollout signal can't see

A rollout can report "ready" while the new version is still wrong: pull recent logs for the just-deployed instances and scan for a crash loop, an elevated error rate, or a startup panic that a readiness probe doesn't catch. If anything here looks wrong, stop and report it — don't proceed to the smoke check against something already unhealthy.

Step 4 — Run one smoke check

Exercise a real, critical-path action end to end (not just a /health endpoint returning 200) — whatever this system's core round-trip is: a request that touches the code you just shipped, not a static page. One meaningful check beats a broad shallow sweep here; the goal is "does the thing users actually do still work," not full regression coverage.

Done when the smoke check has run against the newly-deployed instance and you have a pass/fail result, not an assumption.

Step 5 — Report and stop

• Success — rollout signal cleared, no failure signs in logs, smoke check passed. Stop the loop.
• Failure — name exactly which step failed and what you observed (the specific pod/instance, the specific log line, the specific smoke-check response). Don't just say "deploy looks broken" — a report that isn't actionable defeats the point of automating the watch.
• Timeout — report current state as of the timeout, not a guess about what would happen if you kept waiting.

Do not roll back, restart, or otherwise change the running system as part of this loop — verification surfaces the problem; fixing it is a separate, deliberate decision.