Release Readiness Checklist: What to Verify Before Shipping

A release readiness checklist is a written list of conditions that must hold before a release goes live. Its job is to move the readiness decision from impression to evidence. When a release owner says "we are ready," the checklist shows what that statement rests on.

The list below is a starting point, not a standard. Strike what does not apply to your product and add what is specific to it. The more important choices are which items are required and which are optional, and who owns each item.

How to build the list

Start from your last three incidents or failed releases. For each one, ask which check would have caught it, and add that check. A checklist built from real failures is more useful than one copied from a template, because each line has a reason that the team remembers.

Give every item a verb, an owner and a way to tell it is done. "Security" is a topic. "Dependency scan reviewed, no unresolved high findings, owner: security lead" is a check. A check that cannot be shown to be done is a hope.

Group items by area so that the right person reads the right part. Atlas uses six categories: quality, security, documentation, operations, communication and other. The same grouping works on paper.

Quality checks

• All scope items are complete and accepted against their acceptance criteria.
• Automated tests pass on the exact build that will be released, not an earlier one.
• Regression testing of the areas touched by the scope is complete, including the paths customers use most.
• Known defects are recorded, each with a decision: fixed, accepted for this release or deferred, and by whom.
• Where relevant to the product, performance, accessibility and compatibility checks have been run.
• The release has been exercised in an environment that matches production closely enough to trust the result.

Security checks

• The change has been reviewed for the handling of personal data, credentials and permissions.
• Dependencies have been scanned and any serious finding is resolved or formally accepted.
• New endpoints or screens enforce authentication and authorisation, and the permissions are tested.
• Secrets are read from the environment and none appear in the code or the logs.

Documentation checks

• User-facing documentation describes the new behaviour and the removed behaviour.
• Release notes are drafted and reviewed. See the guide to writing release notes.
• Internal runbooks and support articles are updated for any new failure mode.
• Public interface changes are documented, including anything deprecated.

Operations checks

• Database or data migrations have been run on a realistic copy and the timing is known.
• A rollback plan exists, names its trigger and owner, and has been read by the person who would carry it out.
• Monitoring and alerts cover the new behaviour, so a failure is noticed by the team before it is noticed by a customer.
• Capacity has been considered if the change adds load.
• The on-call engineer for the release window is named and knows what is shipping.
• No freeze window covers the target environment and day.

Communication checks

• Support and customer success have been told what is changing and when.
• Customers who need advance notice, for example because of a changed interface, have received it.
• Internal stakeholders know the release window and where to find the status.
• The channel for reporting problems after release is agreed and visible.

Required versus optional

The most valuable decision is which items block the release. Mark an item required only if shipping without it would be a decision that someone must be willing to defend. Everything else is optional, which means it is recommended, tracked and visible, but it does not stop the release.

Keep a short required list for every release, such as passing tests on the release build, a rollback plan and no active freeze. Add required items for risky releases, for example a security review for a change to authentication. Resist the pull to make everything required. A list of forty required items is ticked in a minute without being read.

Atlas marks each check required or optional, and its readiness score gives required checks 30 percent of the weight. Required checks that are not done appear in the blocker list in plain words.

Keep the list honest

• Review the checklist after each incident that follows a release, and add the check that was missing.
• Retire items that have never failed and never caught anything, after confirming that the risk they covered is gone.
• Do not tick a check on someone else's behalf. The person who owns it marks it done.
• Keep the completed checklist with the release. If something breaks, it shows what was and was not verified.