Worksheet · LC-R03
Deployment checklist
Give every part of a release an owner, evidence and a recovery path, including the work that happens after deployment.
Use this when a release is approaching and it is unclear who would notice if the system silently stopped doing its job.
By Sunil Mathew, co-authored with Claude.
The checklist covers thirteen areas. Copy its eight-column release record into your own document or spreadsheet, then adapt it to your system's risks.
What this helps you decide
Name the action, owner, evidence and recovery path for each area. A small team still needs deliberate boundaries; the number of checklist rows does not establish that the controls work.
Worked example
Illustrative case, not a claimed customer incident.
A service deploys successfully, but the scheduled task that prepares the next period's output is absent. A homepage check passes while the product's main work is not happening.
Verification needs to examine a meaningful task as well as service health. Record when output is due, whether it appears and who responds if it does not. Recovery must recognise completed work before retrying it.
Review before release
| Area | Check and evidence |
|---|---|
| Change | Identify the version, owner, purpose and dependencies. |
| Fast checks | Run relevant type, static and unit checks; record what they do not cover. |
| Environment | Verify configuration parity deliberately; separate secrets and production access. |
| Data | Review migrations, backup and recovery, and compatibility with the previous version. |
| Permissions | Test that routine development and review cannot modify production data. |
| Promotion | Record the approver, evidence and exact version being promoted. |
| Recovery | Explain rollback or forward recovery, including irreversible data changes. |
Review after release
| Area | Check and evidence |
|---|---|
| Service | Verify a meaningful task as well as a health endpoint. |
| Schedule | Verify jobs exist and expected work completes; detect missing success. |
| Observability | Check useful logs and alerts without exposing unnecessary personal data. |
| Response | Name who responds, how they are reached and what recovery they can perform. |
| Repetition | Test that retries and catch-up work do not duplicate completed actions. |
| Deferrals | Record omitted controls, their reason, owner and revisit trigger. |
Complete the release record
Use one row for each of the seven areas before release and six after it. All start at “Not assessed”. Keep that state visible until there is evidence; give a reason for any “Not applicable” decision.
Fill the empty cells with the owner, evidence, unresolved risk and follow-up. A deployment command completing successfully is only one part of the record.
| area | status | owner | evidence | unresolved_risk | next_action | due_date | revisit_trigger |
|---|---|---|---|---|---|---|---|
| Change | Not assessed | ||||||
| Fast checks | Not assessed | ||||||
| Environment | Not assessed | ||||||
| Data | Not assessed | ||||||
| Permissions | Not assessed | ||||||
| Promotion | Not assessed | ||||||
| Recovery | Not assessed | ||||||
| Service | Not assessed | ||||||
| Schedule | Not assessed | ||||||
| Observability | Not assessed | ||||||
| Response | Not assessed | ||||||
| Repetition | Not assessed | ||||||
| Deferrals | Not assessed |
The file is the table above, with the same column names. There is no PDF: printing this page, or saving it as a PDF from the print dialogue, gives you the whole of it as a form.
Limits and next action
The checklist does not prescribe a deployment stack or certify a secure system. Review it against your architecture, risks and obligations.
Next decision: Which missing control would create the most consequential failure in this release? Name its owner and the evidence needed before proceeding.
Supporting records
- The Evaluation-gates worksheet connects each requirement to tested evidence and a release decision.
- The Workflow Cost Limits Worksheet records limits on repeated work, elapsed time and spend.
- The Architecture decision record preserves the reasoning behind a change and its accepted gaps.
Work through deployment as a learning project
Explore Architecting Agentic AI Systems for live guidance across a scoped project's design, evaluation and deployment. Your organisation's production release still needs its own review and authority.