[Workflow] is failing for [affected users] since [time/change], causing [impact]. The current safe workaround is [workaround/none].
Project rescue tool
Urgent software rescue triage checklist
Urgent recovery starts by separating what must be contained now from what must be understood, fixed and improved over time.
When to use this
Use this when a release is blocked, a workflow is unstable or a delivery has stalled. It gives the team a shared incident and recovery picture before an intervention is promised.
- 01
Describe the affected workflow
State who is affected, what fails, when it started, the business or safety impact and the temporary manual route, if one exists.
- 02
Preserve evidence
Collect reproducible steps, logs, environment details, recent changes, error messages and relevant release records. Avoid changing production before the known facts are captured where that is safe to do.
- 03
Identify immediate containment
Decide whether to pause a release, restrict a feature, use a safe fallback, roll back, add monitoring or communicate a known limitation. Containment is not the same as root-cause remediation.
- 04
Map ownership and access
Name the technical owner, business owner, release authority, system provider and person who can grant the access needed to investigate safely.
- 05
Choose a verified change path
Before a fix, agree the environment, test approach, deployment control, rollback route and evidence that will show whether the intervention worked without creating a wider failure.
- 06
Separate the next horizons
Record the immediate containment action, the urgent fix, the reliability improvement and any longer modernisation work as distinct decisions with distinct evidence.
Working prompts to adapt
Before a code or configuration change we need [reproduction], [logs], [environment access], [release authority] and [rollback approach].
The immediate action is [containment]. The condition for an urgent fix is [verification]. Longer-term improvement is owned by [role].