A release introduces a serious defect. What should the team do first?
Release incident responseUse the authorized incident process to contain impact and restore service, preserving evidence. Choose rollback, forward correction, or another response based on data and recovery feasibility.
What to do now
- Confirm impact and activate responsible roles
- Assess safe restoration options
- Execute and verify the chosen response
- Investigate causes after stabilization
When to escalate
There is serious harm, data integrity risk, or essential service disruption.
The technical owner and authorized release decision maker
Example
A release is rolled back only after confirming the database state remains compatible.
Mistake to avoid
Pushing repeated unverified fixes directly into production.
Prevent a repeat
Review real execution evidence and maintainability alongside feature completion; do not treat an unrun test as passed.
Suggested ApprovedFlow setup
- Tasks
- Documents
- Approvals
Track delivery tasks and attach engineering evidence; keep source control, build execution and technical controls in their actual engineering systems. See the platform
Related cases
- Our release process has no monitoring after deployment. What is missing?Unobserved production change
- We discover integration problems only before release. How can we improve?Late integration feedback
- How do we report a serious issue without alarming everyone?Unclear incident communication
- The risk response itself creates a new risk. What should we record?Secondary risk