Release readiness checklist
State machine for go-live criteria and rollout progress tracking.
Every organization has the same conversation after an outage: "Why didn't we catch this before it hit customers?" This template maps the gates that should fire before a release touches production — code review, test pass, staging validation, documentation, and the monitoring checklist for the canary phase.
The blocked states and recovery arrows make it explicit: where does your release get stuck, and what's the recovery? One team's "docs are done" might mean runbooks and alert rules; another's might mean just marketing copy. Tailor the checklist to your risk tolerance, then enforce it.
When to use this template
- Incident postmortems — trace the release: which gate failed to catch the bug? Was it code review, testing, staging, or monitoring? Invest in that gate.
- Release SLA — commit to a checklist and measure it. "50% of releases skip staging" is a process problem worth solving.
- Onboarding new engineers — show the release rhythm before they ship code, so they know what "done" looks like and why each gate exists.
How to adapt it
Add or remove gates based on your team's risk and speed priorities:
- Add a security review gate between code-ready and test-ready if you handle sensitive data; make it a blocking state.
- Insert a customer communication step before canary: stakeholders need to know what's coming so support can prepare for escalations.
- Add a rollback runbook validation gate — don't let deployment start until the rollback procedure is documented and tested.
Drag states to reorder the gates for your workflow — the state machine regenerates Mermaid code automatically.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
stateDiagram-v2
[*] --> Planning
Planning --> CodeReady: Code merged & reviewed
CodeReady --> TestReady: All tests pass
TestReady --> StageReady: Staging pass-off
StageReady --> DocsReady: Docs/runbooks complete
DocsReady --> DepReady: Deployment plan approved
DepReady --> CanaryReady: Canary rollout 10%
CanaryReady --> CriticalMetrics: Monitor 24h for errors
CriticalMetrics --> FullRollout: Expand to 100%
FullRollout --> [*]
Planning --> Blocked1: Merge conflicts / review stuck
TestReady --> Blocked2: Flaky/failing test
StageReady --> Blocked3: Staging regression
DepReady --> Blocked4: Infra unavailable
Blocked1 --> Planning: Fix & retry
Blocked2 --> TestReady: Debug & rerun
Blocked3 --> StageReady: Rollback & fix
Blocked4 --> DepReady: Reschedule
Frequently asked questions
- What is the difference between a release and a deployment?
- A release is the logical grouping of features/fixes (the 'what'), coordinated across teams — product, engineering, ops, docs. A deployment is the technical push to production (the 'how'). A release can involve multiple deployments (blue-green, canary, rolling update) and span weeks of planning. This diagram maps the release readiness gates.
- Why do you need a staging pass-off instead of testing in prod?
- Staging is a safe mirror of production where you can break things and debug without customers seeing errors. It catches infrastructure misconfigurations (wrong secrets, missing environment variables, DNS not updated) that unit tests never find. Teams often skip staging to save time, then waste days debugging in prod.
- What should monitoring look like during canary rollout?
- Watch error rates, latency p99, and any custom metrics your service owns (transaction success, user session completion). Set up alerts: if error_rate spikes 5x or latency doubles, page on-call to roll back. Canary is your early-warning system — use it to catch failures before they hit all customers.
- What do I do if a release blocks at one state?
- The diagram shows recovery paths: code review stuck -> fix & re-review; test failure -> debug & rerun. Document which gates block releases most often in your org, then invest in fixing the bottleneck (is code review taking weeks? add reviewers; are tests flaky? rewrite them). Visual edits show the state machine changing in real time.
Related templates
Canary deployment strategy
Roll out new versions to a small percentage of traffic, then scale up.
Feature release timeline
Gantt chart showing design, build, test, and launch phases.
Feature-to-production timeline
From design kickoff through post-launch monitoring, tracked as milestones.