A go/no-go decision is the point where someone with the authority says yes or no to shipping a release. It works best when the criteria are agreed in advance, the evidence is on the table, and the decision and its reasons are written down.
A go/no-go decision is the checkpoint before a release ships where a named person or group decides whether it goes ahead. It weighs the release's readiness (scope, test results, approvals, risk, dependencies, open incidents and the rollback plan) against agreed criteria, and ends in one of three outcomes: go, no-go, or go on a stated condition.
Write down what must be true to ship: tests passing, approvals held, no blocking incident, dependencies satisfied, no freeze in effect. Deciding the bar during the meeting turns it into an argument.
Pull the answers from the tools that hold them, instead of asking people to recall them. A call that starts with "what is in this release?" has started too late.
A failed hard gate (a blocking incident, a missing mandatory approval, an active freeze) is a no-go unless someone with authority overrides it on the record. Everything else is a judgement about risk.
One named person owns the call, even when many are consulted. A conditional go states the condition and who checks it.
Write down the outcome, the reasons, who decided and any override. It is the record a postmortem or an auditor will ask for.
Real decisions are often neither a clean yes nor a clean no. "Go, if the dependency ships first" or "go for the first region only" is a decision, and it needs an owner and a way to check the condition. Forcing a binary answer pushes teams to say yes with their fingers crossed.
Sometimes the right call is to ship past a failing check. That should be possible, and it should leave a record: who decided, why, and what evidence they relied on. A control nobody can override gets routed around; an override nobody records cannot be defended later.
ArcRelease runs a preflight of seven checks on every release (ceremonies, risk score, open incidents, change freeze, upstream dependencies, approvals and security findings), judges each pass, warn, fail or not checked, and gives the release a GO, NO-GO or CONDITIONAL verdict with the reasons attached. "Not checked" is never counted as a pass. Shipping past a failure takes a signed statement with evidence, and the preflight is snapshotted at that moment.
A short meeting, held shortly before a release, where the people accountable review its readiness against agreed criteria and decide whether it ships. The best ones are brief because the evidence was gathered beforehand.
The decision-maker (named), the release manager, the owners of the services affected, and where relevant QA, security and operations. Many are consulted; one person owns the call.
Scope, test results, approvals, open incidents, freeze status, upstream dependencies, security findings and rollback readiness, agreed before the meeting and written down. The exact list depends on your risk, but it should be stable enough that two releases are judged the same way.
The release may proceed if a stated condition is met, for example a dependency has shipped or a fix has been verified. A good conditional go names the condition, the person who checks it, and what happens if it is not met.
Minutes, when the evidence is ready. A long meeting is usually a sign that the information has not been gathered and the room is reconstructing it.
Record the outcome, the reasons, the evidence considered, who decided and when, and any override with its justification, in a place that cannot be quietly edited afterwards.
Tell us about your release process. Connect your stack in ten minutes, run a Gaja preflight on a real release, and see the reasons behind the verdict.
Free plan · ten minute setup · we reply in one to two business days