Guides & tools / Templates Templates
Keep release stages separate Track checks, upload, provider processing, and public availability separately. This template helps a team avoid declaring a release from an intermediate step.
# Release checklist
Product. [Name]
Version and build. [Exact target]
## Before release
- [ ] Tests and required checks passed
- [ ] Product and legal copy checked
- [ ] Backup or rollback prepared
## Provider stages
| Stage | Actual state | Evidence |
| --- | --- | --- |
| Upload | [State] | [Record] |
| Processing | [State] | [Record] |
| Review or deployment | [State] | [Record] |
| Public availability | [State] | [Record] |
## After release
- [ ] Public result verified
- [ ] Known issues recorded
## Remaining gates
- [Gate and owner]
An ordinary Markdown file. No signup required.
Identify the exact target Write the product, version, and build before checking any provider state. A successful record for a different build is not evidence for this one.
Verify the final public result Open the actual public destination after the provider completes its work. Record pending processing or review without calling it a completed release.
Keep going in MarkThatDown Use MarkThatDown to keep a concise release record and the evidence links together.
Get MarkThatDown free↗ Unlimited notes. Free writing, search, and PDF export. macOS 14 or later.
Useful next steps Meeting notes you can act on↗ Turn a list into a checklist↗ Reviewed October 2, 2026. Maintained by Humenhuk.
Original practical template. Adapt the examples to your own work.