awesomechecklists
llms.txtGitHub ↗
/

35 — Release and Launch Readiness Checklist#

Verify that a new product, service, or significant change is ready for controlled customer exposure, has an explicit go/no-go decision, and can be operated and supported safely after launch. This release-level checklist consolidates sign-offs from deeper reviews rather than duplicating all of their technical tests.

Scope: Backend / API-specific. This file is one part of the 35_Release_and_LaunchReadiness.md checklist. Apply the domain-wide release gate across all applicable scope files; each checklist ID remains unique.

Review details#

  • Project / product:
  • Release / version / environment:
  • Scope and applicable jurisdictions / markets:
  • Launch type / planned window / time zone:
  • Source revision / build artifact / change reference:
  • Launch owner / approver / on-call contacts:
  • Reviewer / owner:
  • Review date:
  • Decision: Pending / Approved / Approved with documented exceptions / Blocked

How to use#

  1. Copy this reusable checklist into project-specific release records; keep the shared template unchecked.
  2. Mark [x] only when a check is verified by a current release plan, required domain sign-off, production smoke test, observable metric, deployment evidence, or accountable decision. Document failures, accepted exceptions, and genuine N/A reasons in project notes or an issue tracker keyed by LAUNCH ID.
  3. Tailor the checklist to the release scope, customer impact, infrastructure, and jurisdiction. Do not assume every application requires canaries, payment checks, app-store distribution, or public indexing.
  4. Complete ## API Checks and ## Frontend Checks separately where the corresponding interface exists. For inapplicable items, document why in project-specific records.
  5. Keep the go/no-go decision independent of having ticked all template items: unresolved material risks need authorized acceptance. Coordinate with Testing, Legal, Security, Accessibility, DevOps, Performance, Reliability, Monitoring, and Data checklists.
  6. Re-run appropriate checks when the release candidate, deployment window, dependencies, target audience, or known risk materially changes.

Launch scope and ownership#

  • LAUNCH-003 Document the launch date, deployment window, expected duration, time zone, and relevant change-freeze periods.
  • LAUNCH-006 Assign owners for each major dependency, external integration, vendor approval, or shared infrastructure change.
  • LAUNCH-019 Schedule explicit review points for go/no-go, initial deployment, traffic expansion, and post-launch acceptance.

Production readiness#

  • LAUNCH-022 Confirm release infrastructure and managed-service dependencies have named owners and documented support arrangements.
  • LAUNCH-024 Ensure production configuration, feature flags, and integration endpoints are reviewed for the actual deployment environment.
  • LAUNCH-025 Validate that required secrets, certificates, signing keys, and deployment identities are available without exposing them in build artifacts or logs.
  • LAUNCH-026 Confirm database migrations, backfills, data imports, and search-index builds are tested and sequenced with the release.
  • LAUNCH-027 Identify irreversible data or infrastructure changes and document safe alternatives to a naïve application rollback.
  • LAUNCH-034 Check relevant dependencies, including authentication, payments, messaging, CDN, DNS, and external APIs, against expected operating limits.
  • LAUNCH-040 Verify capacity and budget for incident response, vendor support, increased traffic, and launch-day infrastructure scaling.

Deployment and rollback#

  • LAUNCH-044 Confirm required CI checks and previous environment promotions passed for the artifact being deployed.
  • LAUNCH-045 Document each deployment step, expected completion condition, accountable operator, and escalation point in a current runbook.
  • LAUNCH-046 Verify production deployment approvals and access controls match organizational policy and actual release risk.
  • LAUNCH-047 Ensure the release sequence accounts for dependent services, API consumers, workers, databases, queues, and background migrations.
  • LAUNCH-048 Check whether old and new application versions must coexist and test their data and API compatibility where relevant.
  • LAUNCH-049 Test environment-specific routing, traffic switching, DNS changes, and cache behavior before initiating deployment.
  • LAUNCH-053 Identify how deployment automation prevents overlapping or obsolete runs from overwriting an active release.
  • LAUNCH-054 Rehearse representative deployment failure scenarios and verify responders know how to halt promotion safely.
  • LAUNCH-060 Validate that migration progress, rollout health, and deployment logs are observable while the release is running.
  • LAUNCH-062 Record deployment decisions, traffic changes, feature-flag settings, and recovery actions against the release identifier.
  • LAUNCH-064 Verify that deployment credentials and production secrets are not exposed through scripts, logs, artifacts, or release communications.
  • LAUNCH-057 Define data reconciliation or compensating actions when rollback cannot undo schema changes or committed side effects.

Post-launch verification#

  • LAUNCH-065 Check the deployed artifact, feature-flag state, environment, schema revision, and active traffic routing against the approved release plan.
  • LAUNCH-069 Review service availability, API errors, tail latency, resource saturation, and queue health over the agreed observation window.
  • LAUNCH-073 Check incident reports, support contacts, social/customer feedback, and other signals that automated telemetry may miss.
  • LAUNCH-071 Validate data integrity, migration completion, record counts, and important business invariants after schema or bulk-data changes.

API Checks#

  • LAUNCH-085 Inventory public and internal API consumers affected by the launch and confirm communication owners for contract changes.
  • LAUNCH-086 Validate that the production API definition or contract version matches the approved release documentation.
  • LAUNCH-087 Run production-safe smoke requests for critical operations, authentication, authorization, and representative roles.
  • LAUNCH-088 Confirm old and new clients remain compatible during staged rollout, cached-client lifetimes, or documented migration windows.
  • LAUNCH-089 Verify expected response codes, validation errors, rate-limit behavior, and retry guidance in the target environment.
  • LAUNCH-090 Check that API gateway, ingress, DNS, TLS, and routing rules point to the intended service versions.
  • LAUNCH-091 Confirm production credentials, scopes, callback URLs, and third-party integration permissions are correct.
  • LAUNCH-092 Test representative webhook or event deliveries, signatures, acknowledgments, and duplicate-handling where applicable.
  • LAUNCH-093 Validate that database migration and schema evolution do not produce missing fields or failures for existing consumers.
  • LAUNCH-094 Check API idempotency for high-impact writes and ensure ambiguous timeouts do not produce duplicate customer actions.
  • LAUNCH-095 Verify health/readiness endpoints are accurate and do not expose protected internals or secrets.
  • LAUNCH-096 Review p95/p99 latency, error rate, and traffic composition for critical operations during initial exposure.
  • LAUNCH-097 Confirm monitoring can separate authentication failures, normal client errors, server faults, and overload throttling.
  • LAUNCH-098 Verify safe rollback or feature-disablement behavior for API consumers when a breaking change or side effect is detected.
  • LAUNCH-099 Ensure API documentation, SDK examples, changelogs, and deprecation notices reflect the deployed public contract.
  • LAUNCH-100 Check that logs and traces contain useful correlation identifiers while excluding sensitive request payloads and credentials.
  • LAUNCH-101 Test graceful handling when upstream dependencies, queues, or downstream providers are unavailable after launch.
  • LAUNCH-102 Confirm responsible consumer teams have a staffed escalation path for launch-day integration regressions.

Release gate#

  • The release scope, exact artifact, target environment, deployment window, and accountable go/no-go owner are documented and agreed.
  • Required technical, operational, security, privacy, accessibility, and business reviews are complete, with no unaccepted release-blocking findings.
  • Production dependencies, migration prerequisites, secrets and access, capacity, monitoring, on-call coverage, and customer-support handoffs are ready for the intended launch.
  • The rollout procedure has clear steps, audience/exposure controls, health thresholds, stop conditions, and safe recovery options, including treatment of irreversible changes.
  • Critical API and frontend journeys are verified in production or an explicitly approved equivalent, with defined follow-up checks after live exposure.
  • Stakeholder/customer communication plans, documentation, known limitations, and escalation channels are approved where applicable.
  • A designated approver has recorded Go, Go with authorized time-bound exceptions, or No-go against the exact release and its residual risks.
  • Post-launch observation, stabilization ownership, completion criteria, and remediation tracking are agreed before the release is declared finished.

Domain-specific approval rule: Block launch when essential user journeys are unverified, required sign-offs are missing, critical dependencies or support coverage are unready, the actual deployed artifact is unknown, or material deployment/recovery risks are unaccepted. A launch approval does not supersede legally required approvals or prove that all risks have been eliminated.

Trusted references and scope#

The following primary sources informed these practical verification questions. Their detailed methods are adaptable rather than mandatory for every organization, and the links are not a claim of any formal launch certification.

Applicability: The depth of review, number of approvals, exposure strategy, and stabilization period depend on customer impact, release type, team size, and applicable obligations. GitHub Actions protections and Workbox service-worker guidance are relevant only when those technologies are used. Reassess the launch plan after any substantial change to the candidate or target environment.

Source review date: 2026-11-12.

Suggested testing tools#

Choose tools appropriate to the project's stack and risks; automation supports evidence but does not approve the checklist.

  • Test focus: release smoke suites, security gates, rollback, and post-deploy verification; include API and service behavior where applicable.
  • Cross-stack: actionlint + Trivy + Playwright.
  • Python: pytest; for pytest-based suites, run python -m pytest -q.
  • TypeScript: Playwright + Vitest; for Vitest-based suites, run npx vitest run (or npx playwright test for E2E).
  • JavaScript: Playwright + Jest; for Jest-based suites, run npx jest --ci (or npx playwright test for E2E).
  • Evidence: Save tool versions, configuration, test environment, fixtures, results, and links in project-specific review records using the existing checklist IDs. Expert review remains necessary where relevant.

Suggested AI skills for verification#

These are optional agent review aids, not automated passes or release approval. Each linked repository had at least 1,000 GitHub stars when checked on 2026-11-12; counts are per repository, not per skill, and do not indicate security or correctness.

  • shipping-and-launch — Review preflight and launch readiness (addyosmani/agent-skills, 116,378 repo stars).
  • verification-before-completion — Require test evidence before a release decision (obra/superpowers, 316,578 repo stars).
  • github-release — Check GitHub release steps where used (github/awesome-copilot, 41,073 repo stars).

How to check: In a project-specific copy, have the agent audit the backend / API scope and map findings to this file's existing checklist IDs, with code/configuration references, reproducible test results, failed or inapplicable cases, and uncertainties. Independently verify findings; keep shared template boxes unchecked and retain human approval requirements.

Before use: Read the skill's SKILL.md, referenced scripts, license, and requested tool permissions. Only execute vetted skills with appropriate access in a controlled environment.

Important warning: reference only#

⚠️ Reference only — not a definitive or exhaustive checklist. This template is a starting point for review, not the ultimate authority or a guarantee of project safety, quality, regulatory compliance, accessibility, security, or launch readiness.

Use project-specific judgment and independent verification. Requirements and risks evolve and differ by project, technology, and jurisdiction. Adapt the checks, consult current authoritative sources, perform relevant tests, and obtain qualified specialist review or approval when appropriate. Checking every box does not replace these steps.

Reference, not a certification. Check applicability, verify important claims against current primary sources, and seek expert review where necessary. Suggest an improvement.