Clean up · Optional companion
Release-risk checklist
For incidents that involved a release, deployment, migration, or other change: screen the change against high-risk indicators, and list the gates that must pass before the next one.
Use it alongside the blameless postmortem workflow — paste it into that conversation when the incident involved a release — or work through it directly with your team.
To use it inside the workflow conversation:
# 07 - Release / Change Risk Checklist
## Phase Gate
Use this file only when the incident involves a release, deployment, migration, infrastructure change, customer-facing change, or operational rollout, or when the facilitator asks for a risk checklist.
After producing or updating the checklist, stop.
## High-Risk Indicators
Classify a release or change as potentially high-risk if it includes any of the following:
### Architecture / infrastructure
- New server, service, queue, worker, listener, database, or external dependency.
- DNS, certificate, cryptographic, auth, token, key, or secret changes.
- Cloud provider, region, network, firewall, proxy, or routing changes.
- Data migration, schema migration, backfill, or irreversible migration.
### Customer or user impact
- Customer/admin action required before or after release.
- Customer-specific configuration required.
- Customer-facing workflow change.
- Notification, email, messaging, upload, access, authentication, billing, or compliance workflow changes.
- Known regulatory, legal, contractual, or SLA sensitivity.
### Operational readiness
- Rollback path is unclear or untested.
- Feature flag state is complex or customer-specific.
- Smoke tests do not mimic affected customer configurations.
- Monitoring does not clearly show success/failure for critical workflows.
- Required subject-matter experts are unavailable during or after release.
## Required Gates for High-Risk Changes
- Customer/user impact assessment completed.
- Required customer/admin actions identified and confirmed.
- Rollback or disable plan documented.
- Monitoring and post-release validation defined.
- Owners assigned for release, technical validation, customer communication, and incident response.
- Standby/recall expectations set for key personnel.
- Legal/security/compliance review completed when needed.
## Stop Condition
After creating or updating the checklist, stop and ask whether the facilitator wants it applied to a specific release or incident. High-risk indicators
Classify a release or change as potentially high-risk if it includes any of the following:
Architecture / infrastructure
- New server, service, queue, worker, listener, database, or external dependency.
- DNS, certificate, cryptographic, auth, token, key, or secret changes.
- Cloud provider, region, network, firewall, proxy, or routing changes.
- Data migration, schema migration, backfill, or irreversible migration.
Customer or user impact
- Customer/admin action required before or after release.
- Customer-specific configuration required.
- Customer-facing workflow change.
- Notification, email, messaging, upload, access, authentication, billing, or compliance workflow changes.
- Known regulatory, legal, contractual, or SLA sensitivity.
Operational readiness
- Rollback path is unclear or untested.
- Feature flag state is complex or customer-specific.
- Smoke tests do not mimic affected customer configurations.
- Monitoring does not clearly show success/failure for critical workflows.
- Required subject-matter experts are unavailable during or after release.
Required gates for high-risk changes
- Customer/user impact assessment completed.
- Required customer/admin actions identified and confirmed.
- Rollback or disable plan documented.
- Monitoring and post-release validation defined.
- Owners assigned for release, technical validation, customer communication, and incident response.
- Standby/recall expectations set for key personnel.
- Legal/security/compliance review completed when needed.