Release Readiness Checklist (2026)

Why a release readiness checklist beats "ship it"

Most production incidents come from things that were skipped, not from things that were tested wrong. The runbook wasn't updated. The new alert wasn't configured. The feature flag wasn't wired so the rollback plan is "hot-fix and pray." The support team learned about the change from a customer ticket. None of these are testing failures — they're operational gaps. A release readiness checklist makes them impossible to overlook.

Five sections, five roles

The checklist maps naturally to the people responsible:

• Code Quality — Engineering Manager. Lint, types, tests, coverage, dependency audit.
• Testing — QA Lead. E2E, contract, performance, accessibility, security, exploratory.
• Observability — SRE / On-call. Logs, metrics, alerts, dashboards, runbook, on-call rota awareness.
• Rollback & Risk — Engineering Manager + SRE. Feature flags, rollback plan, reversible migration, canary, blast radius.
• Communication — Product Owner. Release notes, support brief, status page, stakeholders, customer copy.

The 5-minute rollback target

A rollback that takes 30 minutes during an incident is not a rollback — it's a delay before another decision. Target 5 minutes for the deployment rollback (feature flag flip, blue/green swap, rollback PR). For data migrations, the target is "reversible without data loss" — usually via expand-contract pattern or feature-flag-gated reads. If your release plan's rollback strategy is "forward-fix," you haven't actually planned for failure.

Auto-readiness percentage

The percentage at the top of the checklist is a quick visual signal:

• 100% green — full Go
• 80–99% amber — Conditional Go with documented exceptions
• below 80% red — No-Go or hard conversation about pushing the release

When to run the checklist

24 hours before deploy for normal releases. Before each deploy for high-risk releases (auth, payments, data migration). Skipping the checklist for "small changes" is the classic root cause in the postmortem section "what went wrong."

Common reasons readiness is incomplete (and what to do)

• "Metrics not wired yet" — Document the blind window. Add a P0 action to wire post-release.
• "Runbook outdated" — Update it now, before deploy. It's 10 minutes.
• "Feature flag not wired" — Don't deploy. Wire it, then deploy.
• "Support not briefed" — Schedule the briefing, then deploy. 15 minutes saves hours of ticket triage.
• "Performance not measured" — Run Lighthouse / k6, then deploy. The data exists or you don't deploy.