20 — 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: Frontend-specific. This file is one part of the 20_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.

Post-launch verification#

• LAUNCH-070 Review browser or client-side crashes, failed navigation, page performance, and user-visible errors for targeted cohorts.

Frontend Checks#

• LAUNCH-103 Verify public URLs, app entry points, deep links, navigation, and refresh behavior on the production domain.
• LAUNCH-104 Check production HTML, JavaScript, CSS, images, fonts, and asset manifests load consistently without incompatible cached versions.
• LAUNCH-105 Confirm CDN policies and release invalidation allow users to retrieve the correct application assets after rollout and rollback.
• LAUNCH-106 Validate service-worker update, offline-cache, and installed-app behavior where the product uses these features.
• LAUNCH-107 Verify runtime configuration points to intended production APIs and that no private credentials are embedded in client bundles.
• LAUNCH-108 Run essential workflows on representative supported browsers, devices, viewport sizes, and network conditions.
• LAUNCH-109 Check first-time visits, returning sessions, expired sessions, and account switching for coherent login and state recovery.
• LAUNCH-110 Verify forms, payments, subscriptions, downloads, and other high-impact tasks display correct completion or failure feedback.
• LAUNCH-111 Confirm staged feature flags and user-entitlement rules expose features only to the intended release cohort.
• LAUNCH-112 Review production error boundaries, loading states, and unavailable-service messages for meaningful recovery paths.
• LAUNCH-113 Verify client performance and key page templates against the launch's agreed real-user and laboratory budgets.
• LAUNCH-114 Check that analytics, consent notices, and conversion tracking work without leaking sensitive user data.
• LAUNCH-115 Validate accessibility of critical interactions, including keyboard navigation, focus, form errors, and dynamic status updates.
• LAUNCH-116 Confirm supported languages, currency and date formatting, right-to-left handling, and localized content where applicable.
• LAUNCH-117 Verify production-specific page metadata, canonical URLs, indexing rules, and redirects for externally discoverable sites.
• LAUNCH-118 Check browser error reporting, client-side crash monitoring, and deployed build version tagging after exposure.
• LAUNCH-119 Verify customer-facing release notes, help links, pricing information, and legal notices reflect the released functionality.
• LAUNCH-120 Confirm mobile app store listing, package signing, staged distribution, and rollback limitations when releasing native clients.
• LAUNCH-121 Test concurrent old/new client versions against active API contracts until safe update propagation is expected.
• LAUNCH-122 Ensure that rollback or feature-disablement does not strand users in unfinished transactions or inaccessible flows.

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.

• Google SRE — Reliable Product Launches — launch checklists, dependency review, capacity, operations, and coordinated readiness.
• Google SRE — Launch Coordination Checklist — release-day architecture, load, dependencies, reliability, and verification questions.
• AWS Well-Architected — Operational readiness and change management — consistent prelaunch reviews, personnel, runbooks, change decisions, and support planning.
• AWS Well-Architected — Operational Readiness Reviews — tailored readiness checklists, escalation, event handling, and release quality.
• AWS Well-Architected — Plan for unsuccessful changes — recovery, rollback, feature-disablement, and response to failed releases.
• AWS Well-Architected — Mitigate deployment risks — deployment testing, phased exposure, feedback, and rollback.
• Microsoft Azure Well-Architected — Operational Excellence checklist — ownership, operations, monitoring, incident response, and safe deployment criteria.
• Microsoft Azure Well-Architected — Safe deployment practices — progressive exposure, health gates, emergency changes, and rollback planning.
• Google Cloud — Operational readiness and performance — readiness across workforce, processes, tools, governance, and service support.
• GitHub Docs — Deployments and environments — protected deployment environments and approval mechanisms, when GitHub Actions is used.
• OpenAPI Specification — versioned API contracts and interface documentation, when applicable.
• Chrome for Developers — Service worker deployment — caching and compatibility considerations for service-worker-enabled web apps.

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 browser and client 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 frontend 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.