Quick answer
An incident handoff explains the observed problem, recovery actions, current state, and remaining work. It should help the next person continue without repeating risky changes or assuming the issue is fully resolved.
Before you begin
Gather timestamps, affected URLs, relevant service references, and the change record. Keep logs containing personal data or credentials in approved private storage.
What to do
- State what was observed and which users or functions were affected. Distinguish confirmed facts from suspected causes.
- List actions taken in order, including updates, configuration changes, restores, and temporary workarounds. Identify who authorized consequential actions.
- Record the last verified working state and the checks performed. Include any areas that could not be tested or remain unreliable.
- Document recovery artifacts and how to find them securely. Note the backup time and any newer data that was preserved or may need reconciliation.
- Assign follow-up actions, owners, and review dates. Explain when temporary access, monitoring, or workarounds should be removed.
How to check the result
The next operator should understand what is safe to do and what needs approval. A handoff should not label a service fully restored when only one page or one test passed.
If you need help
For a continuing outage, keep the original support thread and attach the handoff rather than opening conflicting requests. Public status messages should describe verified impact and recovery without exposing internal security details or customer information.
Related help
- Prepare a useful report when a website may be compromised
- Choose a selective rollback instead of restoring everything
- Preserve new orders and inquiries when planning a restore
Official references
Reviewed October 31, 2026. Interfaces, vendor availability, and account features can change. Check your current account before making changes.
