Post-Deployment Verification Checklist
A post deployment checklist with smoke tests and monitoring checks to confirm a release works in production, plus clear rollback triggers. Start it from CI.
- Typical schedule per deployment
- The checklist 5 sections, 19 items
- Variables
{{service}}{{version}}{{environment}} - Start from CI
Use this checklist right after a deployment finishes. Its job is to prove that the new version works for real users, not just that the processes started. It covers smoke tests, monitoring, background work and integrations, and it ends with a clear decision: keep the release, fix forward or roll back. It fits any team that deploys to an environment other people depend on.
Who owns it
The engineer who deployed owns the run and stays until it is complete. For bigger releases, a second person, such as QA or the product owner, can take the functional checks. Automated smoke tests do not replace the run, but their results should be linked in it.
Common pitfalls
- Trusting the health check. A health endpoint shows the process is up. It does not show that login, search or payments work. Test the real flows.
- Comparing with nothing. "Error rate looks fine" means little without a baseline. Compare with the same period before the deploy.
- Forgetting asynchronous work. Queues, cron jobs, emails and webhooks often break quietly and only show up hours later. Check them explicitly.
- Leaving too early. Some problems only appear under peak traffic or at the next batch run. Agree how long you watch, and who checks again later.
- No rollback trigger. Decide in advance which signals mean "roll back now", so nobody argues about it while customers are affected.
The checklist: Verify {{service}} {{version}} after deploy
Rollout state
-
All instances of
{{service}}in{{environment}}report version{{version}} -
No instances are restarting or failing health checks
-
Database migrations finished and the schema version is as expected optional
Smoke tests
-
Automated smoke tests passed and their result is linked
-
Login and logout work for a normal user account
-
The main user flow completes end to end
For example: create a record, edit it and see it in a list, or add to cart and check out.
-
Payment or billing flow works with a test transaction optional
-
The features changed in
{{version}}behave as described in the release notes
Monitoring
-
Error rate is in line with the baseline from before the deploy
-
Latency of the main endpoints is in line with the baseline
-
Logs show no new error types or warning spikes
-
CPU, memory and database connections are within normal range
Background work and integrations
-
Queues are being processed and are not growing
-
Scheduled jobs ran or are scheduled as expected
-
Outgoing emails, webhooks and calls to third-party APIs are succeeding
-
Caches and CDN serve the new version of static assets optional
Decision
-
Decision is recorded: keep, fix forward or roll back, with the reason
-
Later check after the next traffic peak or batch run is assigned to a person optional
-
Team channel is updated with the outcome and any follow-up tickets
Checklist as Markdown
Start this checklist from your pipeline
When the deploy job finishes, POST /api/v1/runs with template "Verify {{service}} {{version}} after deploy" and post the run link to the team channel.
curl -X POST https://runbook.metastic.ch/api/v1/runs \
-H "Authorization: Bearer $RUNBOOK_TOKEN" \
-H "Content-Type: application/json" \
-d '{"template": "Verify {{service}} {{version}} after deploy", "variables": {"service": "…", "version": "…", "environment": "…"}}'Frequently asked questions
What is a smoke test after deployment?
A smoke test is a short set of checks that the most important functions work after a change. It is not a full regression test. It answers whether the release is fundamentally broken, in a few minutes, so you can roll back quickly if it is.
How long should post-deployment monitoring last?
Long enough to see real traffic on the changed code paths. For a busy service, a focused watch of about half an hour plus a check after the next peak is common. For low-traffic services, plan a check after the next batch run or the next working day.
When should I roll back instead of fixing forward?
Roll back when users are clearly affected and the fix is not trivial, or when you do not understand the cause yet. Fix forward when the problem is small, well understood and a fix can ship fast. A rollback is only easy if migrations are backwards compatible, so plan for that before the deploy.
Updated