Post-Deployment Testing Checklist

Execute the synthetic user-path smoke suite (Playwright or Cypress) against the production URL — login, core CRUD path, checkout, and any flows touched by this release. A green CI run against staging is not a substitute; staging data and prod data diverge.

Walk through each item in the changelog as a real user. Don't trust that 'merged + green CI' means 'works in production' — config drift, feature-flag state, and data shape often differ from staging.

Open LaunchDarkly / Unleash / Statsig and verify every flag listed in the release plan matches its intended rollout percentage and target segments. Stale flags are the most common source of 'it works for me' tickets the day after release.

Log in as admin, member, and read-only test accounts. Confirm the access matrix from the spec — pay particular attention to any endpoints touched by this release. Authorization regressions almost never surface in unit tests.

Check the outbound webhook delivery dashboard (Svix, Hookdeck, or in-house) for elevated failure rates over the last hour. Compare to the same hour-of-day from prior week. A breaking schema change on an outbound payload is invisible to your own monitoring until customers complain.

Run a real transaction through Stripe (or your payment processor) using a test card on the live keys, confirm Segment / analytics events fire, verify SSO via Okta / Auth0 still issues a valid session. SDK version drift in dependencies often breaks these silently.

Check the migration table for the expected version, confirm no long-running locks remain, and verify replication lag is back under 1s on read replicas. If a backfill is still running, note its progress and ETA.

Run the reconciliation query — usually a count comparing the source column to the new column, or a checksum on a sampled subset. A backfill that 'completed' but missed rows because of a NULL filter is the classic data-integrity bug.

Latency, traffic, errors, saturation. Compare to the same window last week, not to the last hour pre-deploy (deploy itself often shifts traffic). Flag p99 latency regressions over 20% even if p50 looks normal.

Open Datadog / Sentry / New Relic and check the error rate for each critical service. New error signatures introduced in this release are more important than total volume — a small cluster of new exceptions often signals a code path nobody tested.

Use k6 or Locust to drive 1.5x peak production RPS at the canary or shadow fleet. Watch for autoscaling lag, connection-pool exhaustion, and DB CPU saturation. Capture the run output and attach to the release ticket.

Pull the latest Snyk / Dependabot / GitHub Advanced Security report. Any new Critical or High CVE introduced by this release gets a ticket today, not 'next sprint'. Note the CVE IDs in the release summary.

Spot-check that no secrets appear in build logs, that the new endpoints are HTTPS-only with HSTS, and that the certificate-near-expiration alert is still wired. Run a one-shot gitleaks scan on the release branch.

SOC 2 CC8.1 expects change-management evidence. Confirm the deploy event landed in the audit log with the deploying engineer, sha, and timestamp. If you use Vanta or Drata, confirm the integration picked it up.

Walk the changed pages in each browser plus iOS Safari on a real device. BrowserStack or LambdaTest covers the long tail. Safari's stricter cookie and storage rules catch auth/session bugs that Chrome hides.

Run axe-core or Pa11y against the changed pages. WCAG 2.1 AA is the minimum bar — the EU Accessibility Act (2025) and most public-sector contracts require it. Capture violations and assign owners; don't let them stack up release over release.

Trigger the nightly-equivalent regression in CI against the release sha. Investigate any failure that wasn't already failing on main pre-deploy — flaky tests get a Jira ticket but do not block sign-off; genuine regressions do.

Review the diff against the test files and add coverage for any uncovered branches in the release. The week after deploy is when test gaps are cheapest to close — once it's 'shipped and stable' nobody comes back to it.

Release captain reviews the dashboards, regression result, and any escalations from this checklist. If proceeding, sign off and unlock main. If rolling back, page the on-call and follow the rollback runbook before doing anything else.

Re-deploy the prior tagged image, confirm the previous DB migration is reversed (or that the schema change was forward-compatible), and update the status page. Open a SEV2 incident and start the post-incident review timer.

Only relevant if a migration shipped with this release. Compare row counts pre- and post-migration for the affected tables and confirm checksums on a sampled subset.