Go/No-Go release checklist: criteria and a template you can copy

A Go/No-Go decision is the moment before a release when someone answers one question: given what we tested and what we know is still broken, do we ship this build now? A checklist makes that answer repeatable. Without one, the call depends on who is in the room and how late it is.

This guide covers the criteria that belong on a release readiness checklist, who should make the call, what counts as a No-Go, and a template you can paste into a release ticket or a pull request.

What a Go/No-Go decision is

It is a short review with a recorded outcome. The inputs are the scope of the release, the test results, the open bugs and the state of the things that let you recover if something goes wrong: monitoring, a rollback path and feature flags. The output is one of three answers:

• Go: ship as planned.
• Go with conditions: ship, with named conditions such as a feature kept behind a flag, a known issue written into the release notes, or someone watching the dashboards for the first hour.
• No-Go: do not ship this build. Say what has to change before the next review.

The value is not the meeting. It is that the same questions get asked every time, and that the answer, the reasons and the name of the person who made the call are written down.

Who makes the call

One person decides, and everyone knows who it is before the review starts. In a small company that is often the engineering lead or the founder. A QA engineer brings the evidence and a recommendation. Product owns the scope, and whoever is on call owns the recovery plan.

Two rules keep the decision honest:

1. The person who signs is not the person who wrote the riskiest change. A second pair of eyes is the point.
2. A recommendation comes with its reasons. “No-Go because checkout fails for saved cards on iOS” can be checked and argued with. “Not feeling good about it” cannot.

The Go/No-Go criteria

Group the criteria so that each one has a clear owner and a clear yes or no. Five groups cover most releases.

Scope and change

• The release contains only what was planned, and the change list matches what is in the build.
• Every change has been reviewed and merged through the normal process. Nothing was pushed at the last minute without a review.
• Database migrations are known, tested on data shaped like production, and either reversible or explicitly accepted as one way.

Test results

• The automated suites ran on this exact build, not on an earlier one, and the results are linked.
• Every failure was looked at by a person and labelled as a product bug, a test problem or an environment problem. A red test nobody has looked at blocks a Go.
• The flows that would hurt most if they broke (sign-up, login, checkout, payments, data export) were tested end-to-end on every platform you ship.
• New features had hands-on exploratory testing, not only scripted checks.

Known bugs and open risks

• Every open bug that touches this release has a severity and a decision: fix now, ship with it, or hide the feature.
• No open bug of the highest severity is shipping. If your team uses levels, write down which levels block a release.
• The risks that were not tested are listed. “Not tested on Android 12” is useful information for the person signing.

Operations and recovery

• Monitoring and alerts cover the new code paths, and someone knows which dashboard to watch.
• The rollback path is known and was tried recently, or a feature flag can turn the change off.
• Third-party dependencies that changed (payment provider, auth provider, app store review) are confirmed.

People and timing

• Someone who can fix or roll back is available for the hours after the release.
• The timing avoids known bad windows, such as a Friday evening or a peak sales day, unless there is a reason.
• Support and anyone who talks to customers know what is changing.

Examples of No-Go criteria

Write your No-Go conditions down before the review, so nobody has to invent them under pressure. Examples that work for many web and mobile products:

• A test of a critical flow fails and nobody can yet say whether it is the product or the test.
• A bug of the highest severity is open in this release, with no flag to turn the feature off.
• The suites did not run on the release build.
• A migration cannot be reversed and has not been tried on realistic data.
• The person who can roll back is not available.

A No-Go is not a failure. It is the checklist doing its job, and it is far cheaper than a rollback on a busy afternoon.

The template

Copy this into the release ticket, the release pull request or your team’s chat. Fill it in before the review, not during it.

## Go/No-Go: <release name or version>

Decision: GO | GO WITH CONDITIONS | NO-GO
Decided by: <name>, <date and time, with time zone>
Recommendation from QA: <GO | NO-GO>, because <one or two sentences>

### Scope

- [ ] Change list matches the build: <link>
- [ ] All changes reviewed and merged through the normal process
- [ ] Migrations: <none | list>, reversible: <yes | no, accepted by <name>>

### Tests on this build

- [ ] Automated suites ran on build <id>: <link to results>
- [ ] Every failure triaged: <n> product bugs, <n> test problems, <n> environment problems
- [ ] Critical flows passed on: <web | iOS | Android | API>
- [ ] Exploratory testing of new features: <done | not done, why>

### Open bugs and risks

- [ ] No blocking severity open in this release
- [ ] Known issues shipping: <list, or none>
- [ ] Not tested, and why: <list>

### Recovery

- [ ] Dashboards and alerts for the new code: <link>
- [ ] Rollback path or feature flag: <how>
- [ ] Third parties confirmed: <list, or none>

### People

- [ ] On call after release: <name>, until <time>
- [ ] Support informed: <yes | no>

Conditions (for GO WITH CONDITIONS): <list>
What must change before the next review (for NO-GO): <list>

Keep the filled template. After a few releases it becomes the most honest record you have of what was tested, what was skipped and how often the checklist caught something.

How to run the review in 15 minutes

1. Before the review, the QA engineer fills in the tests and bugs sections and writes a recommendation.
2. In the review, go through the sections in order and stop at every unchecked box. Each one needs an answer: fix it, accept it with a name next to it, or make it a condition.
3. At the end, the person who signs reads the decision out loud and writes it into the template, with the time.
4. After the release, note anything the checklist missed and add a line for next time.

If the review keeps running long, the preparation is the problem, not the meeting. Move the evidence gathering earlier, so the review is a decision and not an investigation.

Making the checklist part of the release

The checklist only works if it cannot be skipped. Put the template into your pull request template for release branches, or make the release job in your CI wait for a recorded decision. Tie it to the evidence: link the test run for the exact build, not a run from yesterday.

This is the release gate our service runs: Claude agents write and run the tests and collect evidence for each failure, a QA engineer triages every failure, and before each release you get a signed Go/No-Go report with what was tested, what failed and what risk is left. Shipping stays your decision. The how it works page shows a week of the service, and our open-source sample project publishes a live Go/No-Go report from CI.

Researched and drafted with Claude, Anthropic's AI model, and checked against the sources it links. Spotted an error? Tell us and we will correct it.