Disaster recovery plan
Detection, failover, validation, and restoration after service outage.
When everything fails at 3 AM, your team's success depends on a clear, pre-rehearsed plan, not heroics. This diagram maps the disaster recovery decision tree: how to detect a critical outage, when to activate failover, how to validate that recovery actually worked, and when it's safe to restore to the primary infrastructure. The branching paths acknowledge reality — sometimes failover fails, requiring manual recovery steps instead.
Every team should have this on their wall or wiki before an incident. It becomes muscle memory in a postmortem review, and it accelerates the critical first 10 minutes when every decision compounds.
When to use this template
- Incident response playbook — each node in this diagram corresponds to a step in your runbook. Annotate with who is responsible, what tools to use, and the exact success criteria before you need it.
- Disaster recovery drills — run a quarterly DRP exercise using this diagram as the script, assigning each team member a role (detection, failover, validation, communication) and timing each gate to find bottlenecks.
- Infrastructure architecture review — show this diagram to stakeholders and flag gaps: "We detect outages in 2 minutes, but our failover takes 10. That 8-minute gap is our RTO — we need to automate it."
How to adapt it
Customize the detection triggers, failover mechanisms, and validation gates to match your infrastructure:
- Replace monitoring detects outage with your actual detection method: synthetic checks, customer-reported errors, alert threshold breach.
- Add specifics to initiate failover — DNS cut-over, database promotion, traffic re-routing to standby region — whatever applies to your stack.
- Expand validate service health into multiple checks: write a test record, query a replica, ping a health endpoint, then fail if any check times out.
The visual editor lets you drag these nodes and rename them without touching code, so your team's final DRP lives here as Mermaid, ready to version-control and link from your incident-response documentation.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Monitoring detects outage] --> B{Severity?}
B -->|Low| C[Notify ops team]
B -->|Critical| D[Declare incident]
D --> E[Activate DRP]
E --> F[Initiate failover]
F --> G{Failover succeeds?}
G -->|No| H[Manual recovery steps]
G -->|Yes| I[Validate service health]
I --> J{All checks pass?}
J -->|No| H
J -->|Yes| K[Restore to primary]
K --> L[Post-incident review]
H --> L
C --> M[Monitor]
M --> N{Resolved?}
N -->|No| C
N -->|Yes| L
Frequently asked questions
- What is a disaster recovery plan diagram?
- A DRP diagram maps the sequence of decisions and actions your team takes when a critical system fails: how you detect the outage, who you notify, what conditions trigger automatic failover, how you validate recovery, and the steps to restore to the primary infrastructure. It makes the usually-chaotic incident response process into a repeatable playbook.
- What's the difference between disaster recovery and business continuity?
- Disaster recovery (DR) is the technical process — detecting, failing over, restoring infrastructure. Business continuity (BC) is the broader strategy: ensuring the business keeps operating during and after that outage, including customer communication, support escalation, and financial impact. A DRP diagram focuses on the technical recovery; a BCP includes the organizational response.
- When should we trigger an automatic failover versus waiting for human approval?
- Automatic failover for clearly-detected, stateless failures (database replica, read cache) where rollback is safe and cheap. Manual approval for stateful systems, data writes, or anything with multi-second recovery time, because a wrong automated decision can turn a 5-minute outage into a 2-hour one. This diagram models both paths.
- How do I adapt this for a multi-region architecture?
- Add a decision point after failover: check which region is primary and which is secondary. If primary region is fully down, promote the secondary; if primary is partially degraded, fail traffic over to the secondary while keeping the primary in read-only to avoid split-brain. Visual edits regenerate clean Mermaid code, so you can document your exact region-failover rules here.
Related templates
Deployment rollback decision tree
Incident detection, severity assessment, and rollback trigger criteria.
Service degradation strategy
Detect failures, trigger graceful fallbacks, maintain partial service.
Incident state machine
States and transitions during an incident from detection to postmortem.