awesomechecklists
llms.txtGitHub ↗
/

15 — 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: Shared / cross-cutting. This file is one part of the 15_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-001 Record whether this is a first launch, major feature, migration, regional rollout, or routine release, and identify the exact product version and intended audience.
  • LAUNCH-004 Name one accountable release owner and a backup with authority to coordinate decisions during the launch.
  • LAUNCH-005 Identify required approvers across product, engineering, operations, security, privacy, legal, and customer support as applicable.
  • LAUNCH-007 Document the release's in-scope features, exclusions, known limitations, and dependencies on other releases.
  • LAUNCH-008 Identify target customer groups, tenants, geographies, languages, device classes, and eligibility rules for rollout.
  • LAUNCH-009 Agree measurable go/no-go criteria, the decision timestamp, and who has final authority to approve or stop the launch.
  • LAUNCH-010 Maintain a single release plan linking the source revision, immutable artifact, change summary, owners, milestones, and evidence locations.
  • LAUNCH-011 Confirm prerequisite product, design, requirements, quality, accessibility, security, privacy, and compliance reviews have been completed where required.
  • LAUNCH-012 Track material open defects and risks by severity, affected user journey, owner, mitigation, and approval status.
  • LAUNCH-013 Verify that blockers cannot be silently downgraded or waived without an authorized, traceable decision.
  • LAUNCH-014 Identify any legal, regulatory, contractual, procurement, or marketplace approvals required before customer exposure.
  • LAUNCH-015 Agree customer-facing terms, pricing, entitlements, data-use notices, and purchase or subscription behavior for launch where applicable.
  • LAUNCH-016 Plan internal announcements, customer notices, release notes, help-center changes, and stakeholder briefings with owners.
  • LAUNCH-017 Define launch-day support capacity, coverage hours, escalation contacts, and alternate communications channels.
  • LAUNCH-018 Confirm customer success, sales, billing, and support teams know what is changing and how to handle predictable questions.
  • LAUNCH-020 Agree a contingency plan for launch delay or cancellation, including who communicates changes to affected users and teams.

Production readiness#

  • LAUNCH-021 Verify the target production environment, domains, networking, DNS, TLS, regional placement, and access rights are provisioned for the intended release.
  • LAUNCH-023 Review projected initial traffic, launch-day spikes, storage growth, quotas, and capacity headroom against recent evidence.
  • LAUNCH-028 Verify backups, restore access, and recovery prerequisites for changes that could corrupt or delete critical data.
  • LAUNCH-029 Confirm essential monitoring dashboards and customer-impact signals are available to launch responders.
  • LAUNCH-030 Ensure critical alerts have tested routing to staffed responders during the release window.
  • LAUNCH-031 Check that health endpoints, synthetic probes, and critical transaction monitoring reflect actual user availability.
  • LAUNCH-032 Verify incident severity criteria, incident commander or equivalent role, and emergency escalation procedures are current.
  • LAUNCH-033 Confirm production runbooks for restart, safe degradation, service restoration, and vendor escalation are accessible.
  • LAUNCH-035 Verify support processes can handle account recovery, failed transactions, customer reports, and requests requiring manual intervention.
  • LAUNCH-036 Confirm required user and operator documentation, accessibility guidance, and help content are available in supported languages.
  • LAUNCH-037 Assess resilience to a dependency outage or partial rollout, with accepted mitigations for unresolved risks.
  • LAUNCH-038 Confirm production permissions and operational controls permit authorized emergency disablement or rollback without unnecessary privilege.
  • LAUNCH-039 Ensure analytics, business event capture, and conversion measurements are configured with applicable consent and data-use limits.
  • LAUNCH-041 Check that all known high-impact defects affecting critical user journeys have been retested or formally accepted by qualified owners.
  • LAUNCH-042 Perform a final readiness review for the intended environment and release scope rather than relying on outdated prior sign-offs.

Deployment and rollback#

  • LAUNCH-043 Record the exact source commit, immutable build artifact, version, configuration, and migration identifiers to be released.

  • LAUNCH-050 Use staged exposure, canary, blue/green, rolling release, or feature flags where the scope and risk justify them.

  • LAUNCH-051 Define initial traffic cohort, expansion steps, wait/observation intervals, and named approval for each promotion.

  • LAUNCH-052 Set measurable thresholds for error rates, latency, availability, transaction failures, and business guardrails that halt rollout.

  • LAUNCH-055 Keep a usable known-good artifact and required prior configuration available for recovery.

  • LAUNCH-056 Document tested rollback, traffic reversal, feature-disablement, and forward-fix options appropriate to the changed components.

  • LAUNCH-058 Confirm operations affecting user sessions, in-flight requests, queued jobs, and streams have safe draining or resumption behavior.

  • LAUNCH-059 Account for CDN, browser, service-worker, mobile-client, and API-version caching that may persist after server rollback.

  • LAUNCH-061 Establish a decision rule for switching from rollback to forward recovery when restoration may be unsafe.

  • LAUNCH-063 Define an emergency hotfix path with appropriately constrained approvals and retrospective review.

Post-launch verification#

  • LAUNCH-066 Run smoke tests in the production environment for critical user journeys immediately after the initial rollout.

  • LAUNCH-067 Verify account creation/login, authorization, primary transactions, and other essential flows appropriate to the product.

  • LAUNCH-068 Confirm that billing, payments, notifications, webhooks, and partner integrations behave as expected where present.

  • LAUNCH-072 Compare real traffic, feature adoption, key funnels, and business guardrails against the prelaunch baseline and forecast.

  • LAUNCH-074 Ensure analytics dashboards and events are actually receiving production data without forbidden personal information.

  • LAUNCH-075 Observe trial cohorts or canary groups independently before expanding the release to additional users or regions.

  • LAUNCH-076 Confirm error-budget or equivalent reliability considerations support further rollout where such policies exist.

  • LAUNCH-077 Verify localized experiences and critical assistive-technology user journeys in production if launch-specific changes affect them.

  • LAUNCH-078 Inspect public landing pages, downloads, deep links, indexing directives, and application entry points where relevant.

  • LAUNCH-079 Verify important third-party integration callbacks and external side effects rather than relying solely on internal health checks.

  • LAUNCH-080 Document whether all go/no-go thresholds remained satisfied during the observation and traffic-expansion stages.

  • LAUNCH-081 Define a post-launch acceptance time, accountable reviewer, and criteria for declaring the release complete.

  • LAUNCH-082 Keep enhanced monitoring, rollback access, and incident coverage in place until the agreed stabilization period ends.

  • LAUNCH-083 Create owned follow-up issues for deferred improvements, nonblocking defects, and observations discovered after launch.

  • LAUNCH-084 Record actual release outcomes, incidents, lessons, and any change to operational runbooks or future launch gates.

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 shared/cross-team controls 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 shared / cross-cutting 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.