A release sign-off checklist that doesn't waste everyone's time

There are two kinds of release sign-off checklist. The first is theatre: a list of "all tests passed? ✅" boxes everyone ticks without thinking, so they prove nothing and stop nothing. The second is the 40-page compliance document that's so heavy people route around it. Both fail for the same reason — they don't change the decision. A useful sign-off does exactly one thing: it forces the question "is there a reason not to ship?" to be answered honestly, in writing, before you ship. Here's the version I use.

The principle: every line can block the release

If a checklist item can't return a "no" that stops the release, delete it — it's decoration. "Tests are green" is decoration if green tests still ship known bugs. "Risky areas tested and signed off, with known issues listed" can actually block. Write the checklist so every line is a real gate, and keep it to one page so people read all of it.

What actually belongs on it

1. Scope is written down and matched. What was this release supposed to change, and does the build match that? Releases go wrong most often because something shipped that nobody meant to include, or the intended change isn't actually in the build.

2. The risky areas were tested — named explicitly. Not "regression done" but "checkout, payments, and login were retested because they're near the change; here's what we ran." Risk-based, because you never have time to test everything — and that's fine if you're deliberate about what you skip.

3. Known issues are listed and accepted. The single most valuable section. Every bug you're shipping with, written down, each with an explicit "accepted by [name]". This converts silent risk into a decision someone owns. A release with three documented, accepted bugs is safer than one claiming zero.

4. It works on a production-like environment. Not just on the test rig — on something that resembles prod (data volume, config, integrations). "Passed in staging, untested against prod config" is a finding, not a pass.

5. The non-functionals were at least glanced at. Did performance regress? Any new accessibility breakage? A 429/error-rate check? These don't need a full pass every release, but "did anyone look?" should be answerable.

6. There's a rollback plan, and someone tried it. What's the undo, who runs it, and has it actually been tested — not just written down? An untested rollback is a hope, not a plan.

7. The right people know it's going out. Support, on-call, and whoever owns the affected area know the timing and what changed. Most "incidents" are really "nobody told support."

How to run it

Fill it in as a record of what happened, not as a wishlist. The value is in the honest "no" — "rollback plan: not tested" written down is the line that saves you, because it makes someone decide whether that's acceptable before 2am. The test plan and sign-off templates have a copyable version, and the broader checklists library covers the area-specific passes (API, accessibility, security) this one points at.

One-page release sign-off

• Release scope is written down and the build matches it
• Risk areas near the change were retested — named, with what was run
• Known issues listed, each explicitly accepted by someone
• Verified on a production-like environment, not just the test rig
• Non-functionals (perf, a11y, error rates) were at least checked
• Rollback plan exists AND has been tested
• Support / on-call / affected owners know it's shipping and what changed