Production Readiness Review Checklist
Three documents and two sheets that track whether each item was checked, whether evidence was attached, and whether a second reviewer verified it holds.
Free download · No account needed
Readiness Checklist by Category, one row
What was checked, what backs it, and who confirmed it still holds
Filled in once test results, monitoring configuration and runbooks are in hand, with a named reviewer set for each category.
Checked
Yes or no, set by the item's own owner. Records only that the owner believes the work is done.
Evidence
A real, named artifact, or "No evidence attached." An item can be checked with nothing behind it.
Verified Status
Set by a named second reviewer, never the item's owner: Verified current, Stale (re-verify), Checked no evidence, or Not started.
Hard Blocker
Security and Rollback & Recovery. One unverified item in either recommends No-Go, regardless of every other row's score.
Every production readiness checklist ranking for this query is a list of boxes: security reviewed, monitoring in place, runbook written, rollback tested. Checking a box records that the item's owner believes the work is done, and nothing else. That person has the least incentive to look closely. Google's own Launch Coordination Engineering team exists because of that gap. LCEs are tasked with acting as gatekeepers, signing off on launches judged safe, a role that works specifically because it sits outside the team under review. A checklist with no equivalent reviewer is measuring intent, not readiness.
Kubernetes formalizes a version of the same separation. A feature's own authors fill out its readiness questionnaire, then a named approver from a separate list reviews it before the feature can merge. That review confirms the feature is operable and safe to roll back, rather than taking the authoring team's word for it. This pack builds that same separation into three tracked facts per item instead of one: whether it was checked, whether real evidence was attached, and whether a named second reviewer confirmed it still holds.
Brightwell Software, a fictional B2B analytics company, ran this checklist against its Webhook Delivery Service v2 ahead of a 17 November 2026 launch. Twenty-one of 24 items were checked, an 87.5 percent naive rate. Eighteen pointed to real evidence, 75.0 percent. Once a second reviewer opened every artifact, only 14 held up as current, 58.3 percent, 29.2 points below the number the room walked in with. Security and Rollback & Recovery, the two hard-blocker categories, each carried an unverified item, which decided the recommendation below, not the score.
What's in the pack
Readiness Checklist by Category
Every item across seven fixed categories, each row carrying whether it was checked, whether real evidence was attached, and who verified it and when.
Gap Register
Every item that did not reach Verified current, with an owner and a due date, so a gap has somewhere to live besides a reviewer's memory.
Readiness Assessment
The three readiness rates explained side by side: the naive checked rate, the evidence-attached rate, and the verified rate a named second reviewer actually confirms.
Go-no-go Recommendation
States the verdict against a fixed rule: any unverified item in a hard-blocker category recommends No-Go outright, before the overall score is even read.
Outstanding Risk Note
One note per gap in a hard-blocker category, leading with what the reviewer actually found and naming the specific artifact that would close it.
A Checked Box Is Not Evidence
The standing rule that keeps a self-reported tick from being mistaken for verification, with the evidence-expiry schedule and who is allowed to confirm each category.
How it works
- 1
Open in River, or take it blank
Claim the pack in River and hand it your service documentation, test results and monitoring configuration, or take the blank checklist and fill it in yourself.
- 2
Build the checklist
River sorts what you send into the fixed categories and records each item as checked or not, with whatever evidence link exists today.
- 3
Verify with a second reviewer
A named reviewer who is not the item's owner opens every piece of evidence and marks it current, stale, or missing entirely.
- 4
Get the go/no-go, rule applied first
The recommendation checks the two hard-blocker categories before it ever looks at the verified rate, so a confident-looking checklist cannot outvote an unverified security gap.
Frequently asked questions
Is this template free?
Yes, no account or card needed to download it. Edit with AI is the optional half, where River builds the checklist from what you send and tracks verification as your second reviewer works through it. Every other pack sits in the template library.
What format are the downloaded files?
Three documents as Word files and two sheets as CSVs, zipped together. The sheets ship with Brightwell Software's illustrative Webhook Delivery Service v2 review already in place, so the gap between checked and verified is visible before you replace the rows with your own service.
How is this different from a normal PRR checklist?
Most production readiness checklists record one fact per item: checked or not. This one records three, because a checked box, a real link to evidence, and a named second reviewer's confirmation are three different claims, and the gap between them is usually the actual finding.
Who should the second reviewer be?
Anyone with the standing to say no to a launch, as long as they are not the item's own owner. Cross-team works well: security review security items, and the on-call lead reviews the rollback and runbook items they would be paged against.
Why are Security and Rollback & Recovery treated differently?
Because they are the two failure modes a launch review cannot afford to get wrong. Every other category's gaps weigh against the 80 percent verified-rate bar; a single unverified item in either of these two recommends No-Go outright, at any overall score.
Does this replace our technical program plan or the exec update?
No. The technical program plan runs the whole programme and its dependency register; this pack is where the go/no-go for one specific launch gets decided. The engineering status update reports that decision upward once it is made. Once the launch happens, what actually went right or wrong belongs in a project retrospective instead.
Find out what 87.5 percent checked actually means
Send the service documentation, test results and monitoring configuration you have. River builds the checklist, and tracks verification as your second reviewer opens each piece of evidence.
Edit with AI