Skip to main content
OpsRoadmaps

Checklists / release-readiness

Release Readiness Checklist

Before a change reaches users: the gates passed, the exposure is controllable, the people who need to know have been told, and the way back is known and timed.

8 steps · 7 required · last reviewed (next review 2027-03-20) · updated 2026-09-20

Related focus areas:ReleaseOps

Sign in to run this checklist

Run this immediately before a release, and keep it short enough that it is used every time rather than skipped under pressure. The single question it exists to force is the one teams most often cannot answer: how do we undo this, and how long does that take?

If an item does not apply to your change, say so explicitly rather than leaving it blank — the record of what was consciously skipped is what makes the next retrospective useful.

  1. The exact artifact being released is identified by version and commit

    required

    "The latest build" is not an identity; without one you cannot say afterwards what was running.

  2. The change can be disabled without a redeploy

    required

    If the only reversal is shipping again, your recovery time is a deployment cycle rather than a switch.

  3. Rollback has been performed recently and its duration is known

    required

    A rollback that exists only as a document is a plan you have never tested under the conditions that need it.

  4. Database changes are backwards-compatible with the currently running version

    required

    Expand-and-contract is what allows a rollback to be safe; a destructive migration makes the deploy one-way.

  5. The functions that will hear about this have been told

    required

    Support and customer-facing teams learning from a ticket is an avoidable, recurring own goal.

  6. Rollout is staged, or the reason it is not has been stated

    required

    Exposing everyone at once is sometimes right; it should be a decision rather than a default.

  7. A named person is watching the release and knows the stop signal

    required

    "Someone will notice" is how a partial failure runs for an hour.

  8. Release notes exist for the audiences that need them, including internal ones

    optional

    The internal audience is the one most often forgotten and the cheapest to serve.

Run it against your real gaps

A checklist is most useful when you know which controls you are actually missing. A free OpsRoadmaps assessment scores your controls with explainable findings and builds a roadmap from the results.

Assess my stack

Checklists document self-reported practice. Items were last reviewed 2026-09-20 — adapt them to your own environment.