A release readiness checklist is the set of twelve gates a release candidate has to clear before it ships: smoke, sanity, regression, system, integration, acceptance, non-functional thresholds, operational readiness, a tested rollback, feature-flag state, a clean data migration, and the go or no-go decision itself, recorded with a name and a timestamp. Each gate needs an owner and a checkable pass condition. Most checklists online describe those rows and stop there. Below is one filled in against a real release candidate, with the pass, waived, and blocked verdicts a working checklist actually produces.
rc-2026.08.4 sat at the gate six hours past its scheduled promote window. Nothing was down. Twelve gates stood between that candidate and a shipped release, and four of them were still marked "in progress" on a whiteboard nobody trusted enough to type "pass" into without rechecking it first.
This is written for the person who has to make that call: an engineer, an SDET, or a release owner deciding whether a candidate ships, or handed a checklist and told to run it. It isn't written for the QA lead building a suite-allocation strategy across an org, the reader asking whether an AI-generated suite tests anything real, or someone picking edge-case inputs for one test case, a full level of detail below anything here. What follows is all twelve gates, filled in against a real release candidate. Every software release checklist you can find online lists roughly these rows; almost none of them show you what the release testing behind a row actually has to produce before you can write "pass" in it.
The Release Readiness Checklist for rc-2026.08.4
rc-2026.08.4 is a release candidate for a checkout and payments update, cut from main after a two-week feature branch merged. Twelve gates stand between that candidate and a shipped release. Each row's pass condition works the same way entry and exit criteria do for a single test phase, just scoped to an entire release: a concrete, checkable condition, not a restatement of the gate's name. If you need the underlying definitions first, smoke, sanity, and system testing are covered elsewhere; this page assumes you already have them and goes straight to the filled artifact.
Six gates in order, from commit to the decision. The full checklist below covers twelve.
| Gate | What "pass" actually means | Owner | Evidence source | Status |
|---|---|---|---|---|
| Smoke green on the candidate | 34/34 smoke checks green, zero retries, on rc-2026.08.4 | Release engineer | CI smoke job run | Pass |
| Sanity on the changed area | 6 checks on the checkout diff (PR #4471) all green | Feature owner | CI sanity job, PR #4471 | Pass |
| Regression suite green or triaged | 412/418 green; 6 red triaged with tickets, none blocking | QA lead | Regression run + triage doc | Waived |
| System test vs the spec | 28/28 spec-mapped scenarios pass end to end | SDET | System test report vs spec | Pass |
| Integration/contract checks | 14/14 contract tests green against the payments broker | Backend lead | Pact broker verification | Pass |
| Acceptance signed (UAT) | Product owner signed off on all 9 acceptance criteria | Product owner | Signed UAT document | Pass |
| Non-functional thresholds met | p95 under 400ms at 2x peak; zero critical axe violations | Perf/accessibility owner | Load report + axe scan | Blocked |
| Operational acceptance (OAT) | Runbook current, backup verified in 24h, on-call briefed | SRE on-call | OAT checklist document | Pass |
| Rollback tested, not just documented | Rollback to prior tag done in staging, under 5 minutes | Release engineer | Rollback drill log | Pass |
| Feature flags in known state | All 3 flags match intended launch state, config diffed | Feature owner | Flag config audit log | Pass |
| Data migration dry-run clean | Dry run vs prod snapshot, zero errors, row counts match | Data/backend lead | Migration dry-run log | Pass |
| Go/no-go decision recorded | Decision logged with name, timestamp, and blocker reference | Release owner | Go/no-go log entry | Pass (No-Go) |
Copy the Gate and Owner columns straight into your own release doc; the pass conditions below are one candidate's, and yours should name your own jobs, brokers and thresholds. Three rows are worth stopping on, because a checklist with twelve green ticks would hide exactly what they show. Row three is waived, not passing: six regression failures are pre-existing, ticketed, and confirmed unrelated to this release, so a human accepted the risk instead of blocking on flakiness. Row seven is blocked: load testing put p95 latency at 640 milliseconds against a 400 millisecond threshold at twice expected peak traffic, and no waiver was requested. Row twelve records the consequence: a no-go, logged with a name, a timestamp, and a pointer back to row seven. Row one's zero-retries condition is worth interrogating further than a single pass or fail; smoke test metrics covers the arithmetic behind whether that gate is actually catching anything.
Machine-Signable vs Human-Signable: What Still Needs a Name Attached
Eight of the twelve rows above are the output of something running: a suite executing, a broker verifying a contract, a dry run replaying a migration against a snapshot. None of those needed a person to interpret them, only to configure what counts as passing in the first place. Rows like rollback and feature-flag state overlap heavily with what a deployment checks gate already verifies before a build promotes. Feature-flag state in particular is only machine-signable if the flags have a declared intended state to diff against, which is the discipline Martin Fowler's write-up on feature toggles calls out as the difference between a toggle and a leftover. The other four rows are different in kind. Acceptance sign-off is a product owner's judgment that the built thing matches what the user actually needed, which a passing suite cannot establish on its own. A waiver is a documented decision to accept a known risk, which requires someone to own that decision by name. A blocked non-functional threshold needs a specialist's read on what "acceptable" means for this release, not just a number compared to a limit. The go/no-go call is always a person signing a name to a consequence, whatever the eleven rows above it say.
| Machine-signable (publishes its own status) | Human-signable (needs a name attached) |
|---|---|
| Smoke, sanity, regression, system | Acceptance sign-off (UAT) |
| Integration/contract checks | Risk waiver reasoning |
| Rollback drill, feature flags, migration | Non-functional threshold call |
| Evidence links and run logs | Go/no-go decision itself |
Eight rows report themselves. Four still need a person's name on the decision.
Why the Checklist Used to Go Stale Inside a Single Release
A release-readiness checklist was, for a long time, a manual bookkeeping artifact. Google's SRE book makes the same point about release engineering as a discipline: reliable services depend on a reproducible release process, not on someone remembering to run one. Someone ran the smoke suite by hand, or waited on whoever did, then typed "pass" into a spreadsheet cell. An hour later the underlying gate moved: regression turned up a new failure, a load test finished with a worse number, a rollback drill that passed last week failed against this week's schema. The cell kept saying what it said when someone last looked at it, which describes the checklist's freshness, not the release's readiness.
When each gate publishes its own status the moment it finishes running, the checklist stops being a document someone fills in and becomes a query against gates that are already reporting for themselves. The result reads closer to what a QA metrics dashboard already does for the rest of a team's testing signal. The only rows still worth filling in by hand are the ones a machine was never going to sign: the judgment calls above, acceptance, the waiver, the call itself.
One loop repeats because it depends on memory. The other repeats because it doesn't need to.
This checklist answers one question: can this candidate ship. Who convenes the room, who holds veto, and what happens the moment a no-go is recorded sits a level up. The checklist lives here; the process lives in the release management process, which the checklist you're reading feeds directly.
How Autonoma Keeps the Checklist Current
The staleness loop above is the exact failure mode our own team kept running into before we built around it. A smoke gate, a sanity check on the changed area, a regression pass, a system test against the spec, even acceptance execution: every one of those rows used to depend on someone remembering to rerun a suite and retype a cell, and the checklist was only ever as fresh as the last person who touched it.
Our agents read the codebase directly rather than working from a saved script, and they verify against the running application rather than a snapshot from last week. One agent plans the test cases a given change actually needs to prove out; another runs them against a live preview of the build; a third reviews each result and separates a real regression from a flaky run or a mismatched plan. The Diffs Agent re-reads every pull request and updates the suite to match it, so the checks feeding rows like smoke, sanity, regression, and system test are current the moment the code changes, not the last time someone remembered to update them.
That covers the behavioral, execution-driven half of this checklist: smoke, sanity, regression, system, and integration/contract execution can publish their own status the moment a run finishes, instead of waiting on a person to check a box. Rollback and feature-flag state still depend on your own deployment tooling to report; monitoring and on-call readiness still come from your own observability stack, not from us. Acceptance's judgment call, the waiver's reasoning, and the go/no-go decision itself stay exactly where the next section puts them, with a person, by name.
What This Checklist Deliberately Leaves to a Person
Not every row on this checklist should be automatic, and a version of this page that pretended otherwise would be worth less, not more. Non-functional thresholds, like row seven's load number, need a specialist's tool built for that job. Load and accessibility testing are their own disciplines, with their own thresholds and their own false positives, and no general-purpose test runner should be trusted to set them. Acceptance sign-off is validation, whether the built thing is right for the user, judged by the person who owns that answer, not verification of whether it was built to spec. Row eight's operational acceptance conditions, runbook currency, backup verification, on-call readiness, are their own gate; operational acceptance testing covers what OAT actually verifies beyond this one summary row. A waiver is a risk decision with a name attached, and a go/no-go call is the same kind of decision at a bigger scale. None of those rows belongs to one vendor. A checklist that routed every one of them to a single tool, or a single team, would get thrown out by the first person asked to defend it to an auditor, and rightly so.
This carveout matters because of who's reading this page. It's written for the engineer, SDET, or release owner staring at a candidate sitting at a gate, not for the person designing a test-allocation strategy for an entire org, or deciding which values to feed into a single test case. Those are real questions. They're just not this one.
Reading Pass, Waived, and Blocked as a Decision, Not a Report Card
Twelve green cells look reassuring and mean almost nothing on their own, because the three-value vocabulary is doing the real work. Pass is an objective, machine-checked condition met exactly as declared. Waived is a Pass a human accepted despite a known gap, with a reason attached and an owner's name on it. Blocked stops the release outright, and it takes exactly one Blocked row to do it, regardless of how many of the other eleven say Pass. rc-2026.08.4 has eleven rows that would let it ship and one that won't, and the checklist's job is making sure that one row wins the argument.
Pass and Waived clear a release on their own. One Blocked row overrides both.
That's also why row twelve exists as its own row instead of being inferred from the other eleven. Recording the decision, who made it, when, and what it was waiting on, is what turns "the checklist looked fine" into an answer you can hand to someone asking six months later why a specific release shipped when it did.
Print this checklist for your own release, but write down real evidence sources for each row before you trust a single cell: a link to the CI run, the pact broker, the load report, the signed UAT document, not a person's memory of having looked at it earlier that day. If half of your twelve rows still depend on someone remembering to rerun a suite and update a cell by hand, that's the actual gap, and it's the same gap Autonoma was built to close on the behavioral half of this list: the smoke, sanity, regression, system, and acceptance-execution rows that can report their own status the moment a change lands, instead of waiting for someone to notice.
Frequently Asked Questions
Twelve gates, at minimum: a green smoke run on the candidate, a sanity pass on whatever changed, a regression suite that's green or explicitly triaged, a system test pass against the spec, integration or contract checks, a signed acceptance review, non-functional thresholds like load and accessibility, an operational acceptance review covering runbooks and monitoring, a tested rollback, a known feature-flag state, a clean data migration dry run, and a recorded go or no-go decision. Each row needs an owner and a concrete, checkable pass condition, not just a name and a blank checkbox.
A waived row is a Pass a person accepted despite a known gap, with a documented reason and a name attached to that decision, the way a regression row can be waived for pre-existing, ticketed failures unrelated to the current release. A blocked row stops the release outright and needs either a fix or an explicit waiver before the candidate can move again. Waived rows still let a release ship; a single blocked row does not, no matter how many other rows are green.
Keep the gate names and the owner column, and delete the status column before you reuse it. Then replace every pass condition with one that is checkable against your own systems: a named CI job rather than 'smoke green', a specific contract broker rather than 'integration checks', a numeric latency and accessibility threshold rather than 'non-functional'. A sign-off template is only useful if each row names the artifact that proves it, so add an evidence column with a link target for every row before the first release runs through it. Rows nobody can point at an artifact for are the rows that will be typed in from memory.
Entry and exit criteria define when it's valid to start or stop a specific test phase, like when a system test cycle is allowed to begin and when it's considered complete. A release readiness checklist sits one level up: it's the set of gates a candidate has to clear across every phase, smoke through go/no-go, before it ships. In practice the exit criteria for each phase usually become the pass condition for that phase's row on the checklist.
It signs the rows a machine should sign, which is most of them. Autonoma generates and runs the behavioral, execution-driven checks, smoke, sanity, regression, system, and acceptance execution, against a live preview of the build, and the Diffs Agent keeps that suite current as the codebase changes, so those rows publish their own status instead of waiting on someone to retest and retype a cell. The remaining rows, non-functional thresholds, the rollback drill, and the acceptance, waiver, and go/no-go judgment calls, stay with the specialists and the names who own them, which is what keeps the checklist trustworthy. Autonoma turns the mechanical majority into a live signal so your team's attention goes to the few rows that genuinely need a human.
Yes, and it is the most common way a checklist misleads. If the checklist is a document someone fills in by hand, the cell reflects whatever was true when it was last checked, not what's true now. A regression suite can turn up a new failure, a load number can regress, or a rollback that worked last week can fail against this week's schema, all without anyone updating the cell. The fix isn't checking more often, it's having each gate publish its own status automatically so the checklist becomes a live query instead of a snapshot.
