Go/no-go decision
In software delivery, a go/no-go decision is the checkpoint at which the people accountable for a release look at the evidence of readiness and decide, on the record, whether it ships on the planned date. Go means the release proceeds; no-go means it is held, and the decision names what has to change before it is asked again. It is binary by design, so that nobody ships on a maybe.
The longer version
The decision is made against a readiness checklist agreed before the meeting rather than assembled in it, and what that list holds is the subject of release readiness. In the meeting each item's owner states whether it is green, amber or red, the open items are argued once, and the decision-maker, typically the product owner or the release manager, calls it and records the call with the date and the reason. A no-go is a normal outcome with a named reason and a new date, and a go taken against an amber item is recorded as an accepted risk with an owner.
The phrase also lives in project management, where a go/no-go gate ends a project phase, and in aviation and spaceflight, where it is the point past which a take-off or launch is no longer aborted; this page is about the software release sense. The nearest neighbours here are release readiness, which is the state of the evidence the decision looks at, and the quality gate, which is a pass-or-fail check the pipeline applies to every change. A go/no-go is a human judgement made once per release on the whole picture, including the things no gate measures.
A go by default is the usual failure: the meeting is scheduled, the evidence is incomplete, and the release goes out because stopping it would need someone to say so out loud. Written criteria and a named decision-maker fix that, because a go against a red item is then a visible choice. A no-go with no exit is the other: the release is held, nobody records what would change the answer, and the next meeting re-argues the same points. Every no-go carries its own conditions for a go.
Common questions
Who makes the go/no-go decision for a software release?
One named person, usually the product owner or the release manager, after hearing from the owners of each readiness item: QA on defects, the business on acceptance, operations on deployment and rollback, support on readiness. A committee vote produces a go by default, because nobody owns the no. One decision-maker with written criteria produces a decision somebody can explain afterwards.
What happens after a no-go decision?
The release is held, and the decision records three things: the item that was red, what would turn it green, and the date the question is asked again. The owners of the red items do that work, the rest of the release does not change, and nobody re-argues the green items at the next meeting. The checklist the decision reads is the subject of release readiness, and it is fixed before the meeting rather than during it.
What is the difference between a go/no-go decision and a quality gate?
A quality gate is automatic, applied to every change by the pipeline, and checks what a machine can measure: tests pass, coverage holds, no new critical findings. A go/no-go decision is human, made once per release, and weighs what the gates passed alongside what no gate can see, such as whether support is ready or a partner date has slipped.
When is a go/no-go meeting held?
Close enough to the release that the evidence is final, and far enough from it that a no-go leaves time to act: for a scheduled release, the working day before the deployment slot, after the last test run on the release candidate and after UAT has closed. Holding it earlier means deciding on stale evidence; holding it an hour before deployment means a no-go has nowhere to go.
How is a go/no-go decision recorded?
As a short entry attached to the release: the date, the decision-maker, the outcome, the state of each readiness item at the time, any item accepted as a risk with its owner, and for a no-go the conditions and the date the question is asked again. The record lives with the release ticket or the readiness checklist, so that a post-incident review can see what was known when the call was made.
Bug reports that arrive ready to triage.
Collect replay, console, network and browser context with the Free plan.