How long should we wait after a deploy before declaring it successful?

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.

Should we have a deployment window?

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.

What if a deploy fails mid-way?

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.

How do we handle database migrations safely?

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.

Who should own the deployment checklist?

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).

Deployment Checklist Template

What This Template Is For

A deployment checklist prevents the kind of mistakes that happen when you ship under pressure: missing database migrations, disabled monitoring, untested rollback plans, and stakeholders who find out about a release from a customer complaint. Every production incident post-mortem eventually includes the line "we should have checked that before deploying."

This template covers the full deployment lifecycle: pre-deployment verification, the deployment itself, post-deployment checks, and rollback procedures. It is designed for SaaS teams deploying to production on a regular cadence (daily, weekly, or per-sprint). Pair it with the Definition of Done template for per-story quality checks and the release planning template for multi-sprint release coordination. The Technical PM Handbook covers the broader topic of managing engineering delivery.

When to Use This Template

Every production deployment: Run through the checklist before and after every deploy.
First deploy for a new team: Establish the deployment process from the start.
After a production incident: Add the missing check to the checklist so it does not happen again.
When onboarding a new engineer: Walk them through the checklist as part of deployment training.

Step-by-Step Instructions

Step 1: Pre-Deployment (30-60 minutes before deploy)

Verify that the code is ready to ship and all stakeholders are informed.

☐ All code changes are merged to the deploy branch
☐ CI/CD pipeline passes (all tests green)
☐ Code reviewed and approved by at least one other engineer
☐ Database migrations tested in staging
☐ Feature flags configured for gradual rollout (if applicable)

Step 2: Deploy (During the deployment window)

Execute the deployment and monitor for immediate issues.

☐ Notify the team in Slack/Teams: "Deploying [version/feature] to production"
☐ Run the deployment script or trigger the CI/CD pipeline
☐ Watch deployment logs for errors
☐ Verify the application starts and health checks pass
☐ Run smoke tests against production

Step 3: Post-Deployment (15-30 minutes after deploy)

Verify that everything works correctly in production and no regressions were introduced.

☐ Verify key user flows in production
☐ Check monitoring dashboards for error rate spikes
☐ Verify database migrations completed successfully
☐ Confirm feature flags are in the expected state
☐ Notify stakeholders: "Deploy complete, all checks passing"

The Deployment Checklist Template

Deploy Date: [Date and time]

Deployer: [Name]

Version/Release: [Version number or release name]

Changes Summary: [Brief list of what is shipping]

Pre-Deployment Checklist

Code Readiness

☐ All PRs merged to deploy branch
☐ CI/CD pipeline green (unit, integration, e2e tests)
☐ Code reviewed and approved
☐ No known P0/P1 bugs in this release
☐ CHANGELOG or release notes updated

Database and Data

☐ Database migrations tested in staging
☐ Migration rollback script prepared and tested
☐ Seed data or config changes applied to staging
☐ No destructive migrations (DROP TABLE, DROP COLUMN) without backup verification

Infrastructure

☐ Environment variables set correctly in production
☐ API keys and secrets rotated if needed
☐ SSL certificates valid (not expiring within 30 days)
☐ CDN cache invalidation plan ready (if static assets changed)
☐ Sufficient server capacity for expected traffic

Feature Flags

☐ Feature flags configured in production (off by default for new features)
☐ Rollout plan defined (% of users, timing)
☐ Kill switch tested (can disable the feature in < 5 minutes)

Communication

☐ Team notified of deployment window
☐ Support team briefed on changes (if user-facing)
☐ Status page ready to update (if applicable)

Deployment Execution

☐ Deployment notification sent to team channel
☐ Deployment triggered at [time]
☐ Deployment logs monitored in real time
☐ Health checks passing
☐ Smoke tests executed

Post-Deployment Verification

Functional Checks

☐ Login flow works
☐ Core user workflows verified (list specific flows below)

- ☐ [Workflow 1: e.g., create new item]

- ☐ [Workflow 2: e.g., process payment]

- ☐ [Workflow 3: e.g., generate report]

☐ API endpoints returning expected responses
☐ Webhooks firing correctly (if applicable)

Performance and Monitoring

☐ Error rate within normal range (< [X]%)
☐ API response times within SLA (p95 < [X]ms)
☐ Memory and CPU usage stable
☐ No new errors in exception tracking (Sentry, Datadog, etc.)
☐ Synthetic monitoring checks passing

Data Integrity

☐ Database migrations completed successfully
☐ No data loss or corruption detected
☐ Background jobs processing correctly
☐ Cache warmed (if applicable)

Rollback Plan

Trigger	Action	Owner	Estimated Time
Error rate > [X]% for 5 minutes	Roll back to previous version	[Name]	[X minutes]
P0 bug reported by users	Disable feature flag, assess impact	[Name]	[X minutes]
Database migration failure	Run rollback migration script	[Name]	[X minutes]
Full rollback needed	Redeploy previous version from CI/CD	[Name]	[X minutes]

Post-Deploy Sign-Off

Check	Status	Verified By	Time
Functional checks	[Pass / Fail]	[Name]	[Time]
Performance checks	[Pass / Fail]	[Name]	[Time]
Data integrity	[Pass / Fail]	[Name]	[Time]
Stakeholder notification sent	[Yes / No]	[Name]	[Time]

Example

Deploy Date: Mar 4, 2026 at 2:00 PM EST

Deployer: Raj (Senior Engineer)

Version: v3.4.2

Changes: Report scheduler, invoice PDF generation, 3 bug fixes

Pre-Deployment

☑ All 7 PRs merged to main
☑ CI pipeline green (247 unit tests, 38 integration, 12 e2e)
☑ All PRs reviewed by Dana or Alex
☑ No open P0/P1 bugs
☑ Database migration (add scheduled_reports table) tested in staging
☑ Rollback migration prepared: DROP TABLE scheduled_reports
☑ Feature flag REPORT_SCHEDULING set to OFF in production
☑ Support team briefed: new "Schedule Report" button in dashboard
☑ Team notified in #deploys channel

Deployment Execution

☑ Deploy triggered at 2:02 PM via GitHub Actions
☑ Build completed at 2:06 PM (4 min)
☑ Health checks passing at 2:07 PM
☑ Smoke tests: login, dashboard load, report generation all passing

Post-Deployment

☑ Login flow: passing
☑ Report generation: passing
☑ Invoice PDF download: passing
☑ Error rate: 0.02% (normal baseline: 0.03%)
☑ API p95: 180ms (normal: 200ms)
☑ scheduled_reports table created, 0 rows (expected)
☑ Feature flag REPORT_SCHEDULING still OFF (will enable for 10% of users tomorrow)

Sign-off: Deploy successful. All checks passing. Feature flag rollout begins Mar 5.

Tips

Automate what you can, checklist what you cannot. CI/CD handles test execution and deployment. The checklist handles the human decisions: is the rollback plan ready? Are stakeholders informed? Did we check the migration? Automated checks catch code issues. Checklists catch process issues.

Deploy during business hours, not Friday evening. If something goes wrong, you want the full team available. Friday deploys mean weekend incidents. Many SaaS teams deploy Tuesday through Thursday, early afternoon.

Keep the rollback plan current. Every deployment should have a documented rollback. "Redeploy the previous version" is a valid rollback plan, but only if you have tested it recently. Feature flags make rollbacks faster because you can disable a feature without redeploying. For more on feature flags in production, see the glossary.

Post-mortems feed the checklist. After every production incident, ask "what check would have prevented this?" and add it to the checklist. The best deployment checklists are built from real failures, not theoretical concerns.

Time-box post-deployment monitoring. Watch dashboards for 15-30 minutes after deploy. If everything is stable, move on. Do not monitor for hours out of anxiety. Set up alerts in your monitoring tool so you get notified if something degrades later. The Product Analytics Handbook covers setting up effective monitoring and alerting.

Deployment Checklist Template