Release readiness checklist: is this release ready to ship?

The release readiness scorecard

Answer for the exact build you are about to ship. Yes means done with evidence, Partly means started or only for some of the release, No means not done. Three questions are marked critical: a No on any of them means the release is not ready, whatever the score.

The release readiness checklist, question by question

Use this as a checklist in your tracker if you prefer. Each item says why it matters and how to close the gap.

1. Scope is written down. Is the scope of this release written down (features, fixes and content) and tied to a specific build? List what is in the release and name the build, commit or deployment it refers to. Every other answer on this list depends on knowing exactly what you are shipping.
2. Checked against requirements. Has every change been checked against its requirements or acceptance criteria, not only against the code? Write acceptance criteria a non-developer could check, then test against them. Tests written from the code share its assumptions. Our UAT sign-off template shows how to phrase criteria an approver can sign.
3. Critical journeys work. Have the critical user journeys (sign-up, log-in, checkout or your equivalent) been tested end to end on this build? Walk every journey that makes or loses money on the exact build you will ship, including error and empty states. The website QA checklist covers the journeys and forms most products need.
4. Regression checked. Have the areas this change could break been re-tested, not just the new feature? Look at what the change touches (shared components, data models, pricing, permissions) and re-test those areas. Most release incidents come from what nobody thought to re-check.
5. Accessibility checked. Have keyboard use, screen reader basics and colour contrast been checked on the changed screens (WCAG 2.2 AA)? Run an automated scan, then check the changed screens with a keyboard alone. Automated rules find only part of the problems, so our AI accessibility testing guide explains what still needs a person.
6. Browsers and devices. Has it been checked on the browsers and screen sizes your users actually use? Use your analytics to pick the browsers and devices that matter, and include at least one small phone. Emulating a phone in a desktop browser helps with layout, but it is not the same as a real device.
7. Integrations and data. Are payments, emails and other integrations tested in sandbox or test mode, with no real customer data? Test each integration end to end in its test mode (payments, email, CRM, analytics) and confirm staging holds no real personal data.
8. Access and privacy. Have access rules been checked, so users cannot see or change each other's data, and are no secrets or personal data exposed? Try the changed pages and APIs as another user and as a signed-out visitor. Broken access control tops the OWASP Top 10 for a reason.
9. Speed and errors. Are page speed and error rates on this build within your targets? Measure the changed pages on a mid-range phone connection and check the error log on staging. Agree the numbers you ship with, before release day.
10. Known issues listed. Are all open issues listed with a severity and an agreed action: fix before release, fix after, or accept? Put every open issue in one list with its severity and the action the release owner agreed. Known issues that are written down are a decision; unknown ones are a surprise.
11. Rollback and monitoring. Can you roll back quickly, and will monitoring tell you within minutes if something breaks after release? Write down how to roll back and who can do it, and make sure alerts cover the critical journeys. A release you cannot undo needs a much higher bar.
12. Sign-off with evidence. Has a named person approved the release, with evidence of what was tested and what was not covered? Record who approved which build, on what terms, with links to the evidence and a plain "not covered" list. The UAT sign-off template gives you the document to sign.

How to run a release readiness review

A release readiness review is a short check just before release where the release owner goes through this list with the people who built and tested it, then decides: go, go with conditions, or no-go.

1. Freeze the scope. Name the build and list what is in it.
2. Bring the evidence. Test results, screenshots, the open issues list and anything not covered.
3. Go through the checklist. Mark each item yes, partly or no, based on evidence rather than memory.
4. Decide and write it down. Go, go with named conditions, or no-go, with the build, the date and the person deciding.
5. Watch the release. Keep someone on monitoring for the first hours and agree the rollback trigger in advance.

What a release readiness report should record

• The release, the build and the date.
• What was checked, against which requirements, with links to the evidence.
• Open issues with severity and the agreed action.
• What was not covered, said plainly.
• The decision, any conditions, and who made it.

Release readiness vs production readiness vs go-live checklists

Production readiness asks whether a service can run reliably in production at all: architecture, capacity, monitoring, failover and on-call. Google's Site Reliability Engineering book publishes its original Launch Coordination Checklist (circa 2005) as an example. Release readiness asks whether this particular release is ready to ship. A go-live checklist is the run-book for the switch-over itself: the steps, owners and timings on the day.

Most teams need all three, at different times: production readiness once per service, release readiness on every release, and a go-live checklist for big launches. Agentic QA can take on much of the release-by-release checking; see how agentic AI testing works.

Sources: Google, Site Reliability Engineering, Appendix E: Launch Coordination Checklist; OWASP Top 10; WCAG 2.2 (W3C). Checked 20 September 2026.