Deployment Checklist Template for PMs

15-30 minutes for most deploys. Check error rates, response times, and core user flows. If you have synthetic monitoring, let one full cycle complete (usually 5-10 minutes). For high-risk deploys (database migrations, infrastructure changes), monitor for 1-2 hours.

Yes, if your team deploys fewer than daily. A consistent window (e.g., Tuesday and Thursday 2-4 PM) gives the team predictability and ensures support staff are available. Teams doing continuous deployment (multiple times per day) rely on automated checks and feature flags instead of windows.

Stop the deployment immediately. Do not try to "fix forward" by pushing another deploy on top. Roll back to the last known good state, investigate the failure, fix it, and redeploy during the next window. Document the failure in the rollback plan section for future reference.

Use a "expand and contract" pattern: add the new column/table first (non-breaking), deploy the code that uses it, then remove the old column in a later deploy. Never deploy destructive migrations (DROP COLUMN, ALTER TYPE) in the same deploy as the code that depends on the change. Test every migration in staging first and always have a rollback script ready.

The engineering team owns and maintains the checklist. The deployer (whoever triggers the deploy) runs through it for each deployment. The tech lead or engineering manager reviews and updates the checklist quarterly. Adding a new check requires team agreement, just like updating the [Definition of Done](/templates/definition-of-done-template).