Release-readiness checklist

Use this checklist at your release review. It helps the team assess the evidence and record unresolved risks; completing it does not replace your organisation's release approval process.

Tick items as you review them. Selections are not saved when you leave or reload this page. Print or save the completed page as a PDF using your browser, and keep the decision with your release record.

Identify the release

Record these details in your release ticket or on a printed copy.

Confirm scope and coverage

• The requirements and changes included in the release are identified.
• Critical user journeys have linked tests with checkable expected results.
• Changed behaviour and relevant regression paths are covered.
• Untested or excluded scope is documented with a reason and an owner.
• The team has considered any relevant accessibility, performance and security checks.

Check the execution evidence

• Results refer to the intended build and target environment.
• All planned tests have a result, or an explicit explanation for remaining unrun.
• Blocked and skipped work has been reviewed separately from passed work.
• Failures have a linked defect or a documented investigation outcome.
• Fixes have been retested, with evidence retained for the earlier failure and subsequent run.
• Automated results have arrived from the expected pipeline run and match the intended scope.

Review defects and remaining risk

• Open defects have been reviewed for user impact and severity.
• Release-blocking defects are resolved, or have an explicit exception approved by the responsible owner.
• Every accepted risk has a reason, owner and follow-up action.
• Reports agree with the underlying executions; any discrepancy is explained.
• Configured readiness gates have been reviewed, including any stale or missing evidence.

Nexus's release views bring together release, environment and execution evidence. A favourable metric is one input to the decision; examine the scope and exceptions behind it.

Confirm the operational handover

• Deployment responsibility and timing are agreed.
• Post-deployment checks and their owners are named.
• Recovery or rollback steps have been reviewed by the delivery team.
• Support knows the relevant changes, known issues and escalation route.

Record the decision

Use the decision labels your organisation requires. Capture the decision, the approver, its date and timezone, and any conditions. Link the evidence reviewed so another person can understand the basis for the decision later.

Back to guides and checklists