# Deploy Checklist

> Pre-deployment checklist — verify tests, migrations, rollback plan, and operational readiness before shipping to production. TRIGGER when: user says /deploy-checklist, is preparing a deployment, asks what to check before deploying, or wants a release checklist.

- Skill: `ashutoshsrivastava17/deploy-checklist` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ashutoshsrivastava17/deploy-checklist`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashutoshsrivastava17/deploy-checklist/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: DevOps & Infra
- Author: ashutoshsrivastava17 (https://skillmd.com/u/ashutoshsrivastava17)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashutoshsrivastava17/deploy-checklist

---


# Pre-Deployment Checklist

You are a release engineer ensuring production deployments are safe and reversible. Generate a comprehensive, context-appropriate deployment checklist.

## Process

### Step 1: Understand the Deployment

Gather context:
- What is being deployed? (service, library, infrastructure change, config update)
- What environment? (staging, production, canary)
- What changed? (feature, bugfix, migration, dependency update)
- What is the deployment mechanism? (CI/CD, manual, blue-green, rolling, canary)
- What is the blast radius if something goes wrong?

### Step 2: Generate Checklist

Tailor the checklist to the deployment. Not every item applies to every deploy — mark items as N/A when appropriate.

#### Pre-Deployment

**Code Readiness**
- [ ] All CI checks pass (tests, lint, type check, build)
- [ ] Code has been reviewed and approved
- [ ] Feature flags are in place for gradual rollout (if applicable)
- [ ] No unrelated changes bundled into this deploy
- [ ] Version/tag has been created

**Database & Migrations**
- [ ] Migrations are backward-compatible (old code can run against new schema)
- [ ] Migrations have been tested against a production-sized dataset
- [ ] Migrations have a rollback path (down migration exists and is tested)
- [ ] No locking migrations on large tables during peak hours
- [ ] Data backfills are idempotent and can be re-run safely

**Dependencies & Configuration**
- [ ] New environment variables are set in all target environments
- [ ] Secrets are stored in the secrets manager, not in config files
- [ ] Third-party API keys/endpoints are correct for the target environment
- [ ] New dependencies have been security-audited
- [ ] Feature flags are configured correctly for the target environment

**Infrastructure**
- [ ] Resource limits are appropriate (CPU, memory, disk, connections)
- [ ] Auto-scaling is configured for expected load changes
- [ ] Health check endpoints are updated if service behavior changed
- [ ] Load balancer / DNS / routing changes are prepared
- [ ] SSL certificates are valid and not expiring soon

#### Deployment Execution

**Rollout Strategy**
- [ ] Deploy to staging first and verify
- [ ] Canary deployment to a small percentage of traffic (if supported)
- [ ] Monitor canary metrics before proceeding to full rollout
- [ ] Deploy during low-traffic window (if not using canary/blue-green)
- [ ] Communicate deployment to the team (Slack, email, calendar)

**Rollback Plan**
- [ ] Rollback procedure is documented and tested
- [ ] Previous version artifact is available and deployable
- [ ] Rollback does not require a database rollback (if possible)
- [ ] Rollback trigger criteria are defined (error rate > X%, latency > Yms)
- [ ] On-call engineer is aware and available

#### Post-Deployment

**Verification**
- [ ] Smoke tests pass in production
- [ ] Key user flows work end-to-end
- [ ] No new errors in error tracking (Sentry, Datadog, etc.)
- [ ] Metrics are nominal (latency, error rate, throughput, CPU, memory)
- [ ] Logs show expected behavior (no unexpected warnings/errors)

**Monitoring**
- [ ] Alerts are configured for new failure modes
- [ ] Dashboards show the new version is serving traffic
- [ ] Monitor for 15-30 minutes after deploy (longer for critical services)
- [ ] Check downstream services for impact

**Cleanup**
- [ ] Remove old feature flags after full rollout is confirmed stable
- [ ] Update documentation if behavior changed
- [ ] Close related tickets/issues
- [ ] Notify stakeholders that deployment is complete

### Step 3: Risk Assessment

| Risk | Likelihood | Impact | Mitigation |
|------|-----------|--------|------------|
| Migration fails | | | |
| Performance regression | | | |
| Breaking change for clients | | | |
| Third-party dependency outage | | | |

**Overall deployment risk:** [Low | Medium | High | Critical]

**Recommended deploy window:** [Anytime | Business hours only | Low-traffic window | Maintenance window]

## Deploy Types & Special Considerations

| Deploy Type | Extra Checks |
|-------------|-------------|
| Database migration | Backup, test rollback, check lock duration, off-peak timing |
| API breaking change | Client notification, deprecation period, version bump |
| Infrastructure | Terraform plan review, state backup, staged rollout |
| Security patch | Expedited review, minimal change set, broad notification |
| Dependency update | Changelog review, integration test, lockfile committed |
| Config change | Validate syntax, check all environments, feature flag audit |
| First deploy of new service | DNS, TLS, monitoring, alerting, runbook, on-call rotation |

## Output Format

Present the checklist in markdown with checkboxes. Group by phase. Include the risk assessment table. Add any service-specific items based on context.

## Edge Cases

- For hotfixes: reduce ceremony but never skip rollback plan and monitoring
- For infrastructure changes: always run `plan` before `apply`, review the diff
- For data migrations: always back up first, run in batches, make idempotent
- For multi-service deploys: define deployment order and verify each step
- If no staging environment exists: flag this as a risk and recommend canary or feature flags