30 Claude Prompts for Disaster Recovery

You are a senior operations engineer who writes failover runbooks that a tired on-call engineer can follow at 3 a.m. <context> I need a draft runbook for failing the primary environment over to a secondary environment for one system I own. </context> <inputs> - System name: [SYSTEM NAME] - Primary environment: [PRIMARY ENVIRONMENT] - Secondary environment: [SECONDARY ENVIRONMENT] - Known health checks: [HEALTH CHECK LIST] - People who can approve the cut: [APPROVER ROLES] </inputs> <task> Draft a step-by-step failover runbook from [PRIMARY ENVIRONMENT] to [SECONDARY ENVIRONMENT]. Include a go or no-go check, the cut steps, and a verify list. Do not invent recovery times. If a step needs a time I did not give, write WAIT FOR OWNER CONFIRMATION. </task> <constraints> This is an operational draft for the owner of the system to verify. Do not claim the runbook is production-ready. Do not invent console paths I did not name. Keep each step to two sentences or fewer. </constraints> <format> Return numbered steps grouped as Decide, Cut, Verify, and Stop if unsafe. End with a short list of facts [APPROVER ROLES] must confirm before anyone uses this in an incident. </format>

You are a database reliability engineer who writes decision trees for when to fail a database over and when to wait. <context> I need a draft decision tree for a database failover so on-call does not jump to a cut without the owner agreeing on the triggers. </context> <inputs> - Database name: [DATABASE NAME] - Topology: [PRIMARY REPLICA TOPOLOGY] - Observed symptoms that started this work: [SYMPTOM LIST] - People who can approve a cut: [APPROVER ROLES] - Last successful failover drill, if any: [LAST DRILL OR NEVER] </inputs> <task> Draft a decision tree that starts from [SYMPTOM LIST] and branches into wait, escalate, or fail over. Each leaf must name who decides. Do not invent a recovery time. If [LAST DRILL OR NEVER] is NEVER, mark the fail-over leaf as UNVERIFIED DRAFT. </task> <constraints> This is a draft for the owner of the system to verify. Do not claim the tree is production-ready. Do not invent replica lag numbers. Keep the tree to 12 nodes or fewer. </constraints> <format> Return the tree as indented text with Yes and No branches, then a short list of measurements [APPROVER ROLES] still need to supply. </format>

You are a platform engineer who writes DNS cutover checklists that prevent a half-flipped record from becoming a second outage. <context> I need a draft checklist for changing DNS during a disaster recovery cutover for one service. </context> <inputs> - Service hostname: [SERVICE HOSTNAME] - DNS provider: [DNS PROVIDER] - Current record type and target: [CURRENT RECORD] - Intended target after cut: [INTENDED TARGET] - TTL we actually have today: [CURRENT TTL OR UNKNOWN] </inputs> <task> Draft a DNS cutover checklist covering pre-checks, the change, and post-change verification. Do not invent a TTL or a propagation time. If [CURRENT TTL OR UNKNOWN] is UNKNOWN, add a blocker step that the owner must look up the live TTL first. </task> <constraints> This is an operational draft for the owner of the system to verify. Do not claim the checklist is production-ready. Do not invent registrar or provider UI clicks I did not name. Keep the list under 20 steps. </constraints> <format> Return three numbered lists titled Before the change, During the change, After the change. Flag any step that depends on a fact I left unknown. </format>

You are a disaster recovery coordinator who writes failback runbooks so a team does not stay on a temporary site longer than they meant to. <context> We failed over or restored to a temporary environment. I need a draft failback runbook to return traffic to the original site once the owner says it is safe. </context> <inputs> - System name: [SYSTEM NAME] - Temporary environment in use: [TEMPORARY ENVIRONMENT] - Original environment: [ORIGINAL ENVIRONMENT] - Data catch-up method, if known: [CATCH UP METHOD OR UNKNOWN] - Owner who approves failback: [SYSTEM OWNER NAME] </inputs> <task> Draft a failback runbook that covers data catch-up, a freeze window, the cut back, and a verify list. Do not invent how long catch-up takes. If [CATCH UP METHOD OR UNKNOWN] is UNKNOWN, write a required owner task to name the method before any cut back. </task> <constraints> This is a draft for [SYSTEM OWNER NAME] to verify. Do not claim failback is production-ready. Do not invent recovery times. Keep each step to two sentences or fewer. </constraints> <format> Return numbered steps grouped as Prepare, Freeze and catch up, Cut back, Verify. End with a stop list of conditions that should abort failback. </format>

You are a reliability architect who sequences multi-region failover so dependent services do not cut in the wrong order. <context> I need a draft sequence for failing a stack over across regions. I will have the owners of each service confirm the order. </context> <inputs> - Regions involved: [REGION LIST] - Services in the stack: [SERVICE LIST] - Known hard dependencies: [DEPENDENCY NOTES] - Shared data stores: [SHARED DATA STORES] - Coordinating owner: [COORDINATING OWNER] </inputs> <task> Draft a region failover sequence that orders [SERVICE LIST] using only [DEPENDENCY NOTES]. Do not invent a recovery time for any hop. If a dependency is unclear, insert a HOLD FOR OWNER step instead of guessing the order. </task> <constraints> This is an operational draft for [COORDINATING OWNER] and each service owner to verify. Do not claim the sequence is production-ready. Do not invent cross-region lag. Keep the sequence to one page. </constraints> <format> Return a numbered sequence with columns Step, Service, Depends on, Owner confirmation needed. Follow with a list of facts still missing from [DEPENDENCY NOTES]. </format>

You are a disaster recovery exercise facilitator who writes tabletop scripts that force a team to find gaps without touching production. <context> I need a draft tabletop script for a disaster recovery exercise so we can walk through a scenario and write down what we do not know. </context> <inputs> - Scenario to walk through: [SCENARIO DESCRIPTION] - Systems in the exercise: [SYSTEM LIST] - Roles in the room: [ROLE LIST] - Timebox for the session: [SESSION LENGTH] - Facilitator: [FACILITATOR NAME] </inputs> <task> Draft a tabletop script with timed injects, questions for each role, and a capture sheet for gaps. Do not invent recovery times as expected answers. Every inject should ask the team what they would do and what they cannot prove. </task> <constraints> This is a draft for [FACILITATOR NAME] and the owners of [SYSTEM LIST] to verify before the session. Do not claim the exercise is production-ready. Do not score the team against invented SLAs. Fit the script to [SESSION LENGTH]. </constraints> <format> Return a timed agenda, then inject cards with time, inject text, and questions. End with a blank gap log the scribe can fill during the room. </format>

You are a reliability engineer who designs partial failover tests that prove one slice of recovery without taking the whole product down. <context> I want a draft test plan for a partial failover, such as one service or one data store, so we can practice without a full cutover. </context> <inputs> - System or slice under test: [SLICE NAME] - Production impact we will accept: [ACCEPTED IMPACT] - Rollback method: [ROLLBACK METHOD] - Success signals we can actually observe: [OBSERVABLE SIGNALS] - Test owner: [TEST OWNER] </inputs> <task> Draft a partial failover test plan with pre-checks, the test steps, rollback, and how we record the result. Do not invent a recovery time as a pass bar. Use only [OBSERVABLE SIGNALS] as success criteria. If a signal is missing, mark it as a blocker for [TEST OWNER]. </task> <constraints> This is an operational draft for the owner of the system to verify. Do not claim the plan is production-ready. Do not expand the blast radius past [ACCEPTED IMPACT]. Keep the plan under 400 words. </constraints> <format> Return sections for Scope, Pre-checks, Test steps, Rollback, Result log. Use numbered steps. Flag any step that needs a fact I did not give. </format>

You are an operations lead who writes full cutover test plans that leadership can reject or approve with eyes open. <context> I need a draft plan for a full disaster recovery cutover test. This is not permission to run it. The owner still has to approve every step. </context> <inputs> - Systems in the full cut: [SYSTEM LIST] - Maintenance window we have, if any: [WINDOW OR NONE] - Customer communication owner: [COMMS OWNER] - Abort conditions we already agree on: [ABORT CONDITIONS] - Executive sponsor: [SPONSOR NAME] </inputs> <task> Draft a full cutover test plan covering freeze, cut, verify, failback, and abort. Do not invent how long the cut will take. If [WINDOW OR NONE] is NONE, state that the owner must set a window before this draft can be scheduled. </task> <constraints> This is an operational draft for [SPONSOR NAME] and each system owner to verify. Do not claim the plan is production-ready. Do not invent recovery times. Keep customer-facing claims out of the plan body and point [COMMS OWNER] to a separate draft. </constraints> <format> Return a one-page plan with numbered phases, an abort table using [ABORT CONDITIONS], and a sign-off list of owners who must accept or reject the draft. </format>

You are a quality lead for reliability programs who writes success criteria that a test owner can score without arguing after the fact. <context> I need draft success criteria for a disaster recovery test so we agree what pass and fail mean before we start. </context> <inputs> - Test type: [TABLETOP OR PARTIAL OR FULL] - System under test: [SYSTEM NAME] - Signals we can measure: [MEASURABLE SIGNALS] - Signals we cannot measure yet: [UNMEASURED SIGNALS] - Test owner: [TEST OWNER] </inputs> <task> Draft success criteria that use only [MEASURABLE SIGNALS] as pass or fail. List [UNMEASURED SIGNALS] as gaps, not as criteria. Do not invent a recovery time threshold. If I want time-based criteria later, tell [TEST OWNER] what to measure in a future drill first. </task> <constraints> This is a draft for the owner of the system to verify. Do not claim the criteria make the plan production-ready. Do not turn unmeasured items into pass bars. Keep the list to 10 criteria or fewer. </constraints> <format> Return a table with columns Criterion, Signal used, Pass if, Fail if. Then a gap list titled Cannot score yet. </format>

You are an incident and exercise scribe who writes after-action reports that stick to what the team observed. <context> We just ran a disaster recovery test. I need a draft after-action report from my notes, not a polished success story. </context> <inputs> - Test date and type: [TEST DATE AND TYPE] - Systems exercised: [SYSTEM LIST] - What we observed: [OBSERVATION NOTES] - What we could not complete: [INCOMPLETE STEPS] - Report owner: [REPORT OWNER] </inputs> <task> Draft an after-action report that states what was tested, what worked, what failed or was skipped, and what [REPORT OWNER] should assign next. Do not invent a recovery time. Do not upgrade a skipped step into a pass. Quote my notes rather than smoothing them. </task> <constraints> This is a draft for the owner of each system to verify. Do not claim the test proved production readiness. Do not invent metrics I did not supply. Keep the report under 500 words. </constraints> <format> Return headings for Scope, Timeline of what we did, Findings, Incomplete work, and Proposed next actions. Use bullets. Mark any finding that is an inference, not an observation. </format>

You are a systems analyst who builds upstream dependency inventories that a recovery owner can walk during an outage. <context> I need a draft inventory of what [SYSTEM NAME] depends on so we know what must be up before we call the system recovered. </context> <inputs> - System name: [SYSTEM NAME] - Known upstream services: [UPSTREAM SERVICE LIST] - Known data stores: [DATA STORE LIST] - Identity or network prerequisites: [PREREQUISITE LIST] - Owner of the inventory: [SYSTEM OWNER NAME] </inputs> <task> Draft an upstream dependency inventory that lists each dependency, why recovery needs it, and who owns it if I named an owner. Do not invent dependencies I did not list. If a critical class is missing from my lists, add a question for [SYSTEM OWNER NAME] instead of filling it in. </task> <constraints> This is an operational draft for the owner of the system to verify. Do not claim the map is complete or production-ready. Do not invent recovery times for any dependency. Keep one row per dependency. </constraints> <format> Return a table with columns Dependency, Type, Why recovery needs it, Owner if known, Open question. End with a short list of classes I did not mention, framed as questions only. </format>

You are a product operations analyst who maps what breaks for customers and internal teams when one system is down. <context> I need a draft downstream impact map for an outage of one system so comms and recovery can see who feels it. </context> <inputs> - System name: [SYSTEM NAME] - Known downstream consumers: [CONSUMER LIST] - User-facing features that stop: [FEATURE LIST] - Internal teams that wait on it: [INTERNAL TEAM LIST] - Map owner: [SYSTEM OWNER NAME] </inputs> <task> Draft a downstream impact map that ties each consumer and feature to the outage of [SYSTEM NAME]. Do not invent a customer count or a recovery time. If I did not name a consumer that seems likely, ask [SYSTEM OWNER NAME] instead of adding it as fact. </task> <constraints> This is a draft for the owner of the system to verify. Do not claim the map is production-ready. Do not invent revenue impact. Keep the map to one page. </constraints> <format> Return two lists: External or customer impact, and Internal impact. Then a table with columns Consumer, What stops, Who to notify. Mark any row that is a guess. </format>

You are a vendor risk analyst who lists third-party dependencies that can block disaster recovery even when your own stack is healthy. <context> I need a draft list of vendors this system depends on during recovery, including who we call and what we do not know. </context> <inputs> - System name: [SYSTEM NAME] - Vendors in the path: [VENDOR LIST] - Support contacts we have on file: [CONTACT LIST OR NONE] - Contract or status page notes: [VENDOR NOTES] - List owner: [SYSTEM OWNER NAME] </inputs> <task> Draft a third-party dependency list for recovery. For each vendor, state what recovery needs from them, what contact I supplied, and what is missing. Do not invent a vendor SLA or a restore time. If [CONTACT LIST OR NONE] is NONE, mark every row as missing a verified contact. </task> <constraints> This is an operational draft for [SYSTEM OWNER NAME] to verify. Do not claim the list is production-ready. Do not invent phone numbers or severity definitions. Keep one row per vendor. </constraints> <format> Return a table with columns Vendor, Needed during recovery, Contact on file, Missing fact. Follow with three questions the owner should take to procurement or the vendor manager. </format>

You are a data engineer who draws recovery-oriented data flow maps so restore order matches how data actually moves. <context> I need a draft data flow map that shows how data enters, moves, and is copied for one system, so we restore in a safe order. </context> <inputs> - System name: [SYSTEM NAME] - Sources of data: [SOURCE LIST] - Stores and queues: [STORE AND QUEUE LIST] - Downstream sinks: [SINK LIST] - Copy or backup jobs we know about: [COPY JOB LIST OR UNKNOWN] </inputs> <task> Draft a data flow map for recovery that orders sources, stores, and sinks. Propose a restore order only where my lists make the order obvious. If [COPY JOB LIST OR UNKNOWN] is UNKNOWN, do not invent a backup path. Ask the owner to name the copy job before anyone treats the order as final. </task> <constraints> This is a draft for the owner of the system to verify. Do not claim the map is production-ready. Do not invent recovery times or lag. Keep the map readable by an on-call engineer who is not a data specialist. </constraints> <format> Return a mermaid or plain numbered flow from source to sink, then a restore-order list with a HOLD row wherever the copy path is unknown. </format>

You are a recovery planner who turns a dependency list into a critical path so a team restores the blocking items first. <context> I have a pile of systems and dependencies. I need a draft critical path that says what must come back before the rest can start. </context> <inputs> - Top-level system we want recovered: [SYSTEM NAME] - Dependency notes: [DEPENDENCY NOTES] - Teams who would do the work: [TEAM LIST] - Known blockers from the last incident: [KNOWN BLOCKERS OR NONE] - Path owner: [SYSTEM OWNER NAME] </inputs> <task> Draft a critical path for restore order using only [DEPENDENCY NOTES] and [KNOWN BLOCKERS OR NONE]. Do not invent a duration for any node. If two items could be in either order, say so and ask [SYSTEM OWNER NAME] to pick. </task> <constraints> This is an operational draft for the owner of the system to verify. Do not claim the path is production-ready. Do not invent recovery times. Limit the path to 15 nodes. </constraints> <format> Return a numbered critical path, a short parallel-work list, and a question list for [TEAM LIST]. Mark any node that sits on an assumption. </format>

You are a backup administrator who reviews coverage against the stores a team says they care about. <context> I need a draft backup coverage review that shows which stores have a known copy job and which ones I have not proven. </context> <inputs> - System name: [SYSTEM NAME] - Stores that must be recoverable: [STORE LIST] - Known backup or snapshot jobs: [JOB LIST OR UNKNOWN] - Last successful restore per job, if any: [LAST RESTORE NOTES OR NEVER] - Review owner: [SYSTEM OWNER NAME] </inputs> <task> Draft a coverage review that maps each store to a job I named. If [JOB LIST OR UNKNOWN] is UNKNOWN, mark every store as UNPROVEN. Do not invent a backup interval or a restore time. Treat NEVER as a gap, not as a pass. </task> <constraints> This is an operational draft for [SYSTEM OWNER NAME] to verify. Do not claim coverage is production-ready. Do not invent retention days. Keep the review under 350 words plus the table. </constraints> <format> Return a table with columns Store, Job if named, Last proven restore, Gap. Follow with questions the owner should answer before anyone calls backups complete. </format>

You are a senior systems administrator who writes restore procedures that an on-call engineer can follow without guessing. <context> I need a draft restore procedure for one data store. I will have the owner of the system walk it before anyone treats it as the real runbook. </context> <inputs> - Data store name: [DATA STORE NAME] - Restore source we actually have: [RESTORE SOURCE] - Destination environment: [DESTINATION ENVIRONMENT] - People allowed to run the restore: [OPERATOR ROLES] - Known risks during restore: [KNOWN RISKS] </inputs> <task> Draft a restore procedure from [RESTORE SOURCE] into [DESTINATION ENVIRONMENT]. Include pre-checks, the restore steps, and verification. Do not invent how long the restore takes. If a command or console path is not something I named, write OWNER MUST SUPPLY COMMAND instead of guessing. </task> <constraints> This is an operational draft for the owner of the system to verify. Do not claim the procedure is production-ready. Do not invent recovery times. Keep each step to two sentences or fewer. </constraints> <format> Return numbered steps grouped as Pre-checks, Restore, Verify, and If it fails. List [KNOWN RISKS] as stop-and-ask items, not as footnotes. </format>

You are a data retention specialist who drafts backup retention schedules from policy notes a team already has, not from invented legal advice. <context> I need a draft retention schedule for backups of one system. Legal and the system owner still have to confirm every period. </context> <inputs> - System name: [SYSTEM NAME] - Backup types in use: [BACKUP TYPE LIST] - Stated retention we already follow, if any: [STATED RETENTION OR NONE] - Compliance notes we already have: [COMPLIANCE NOTES OR NONE] - Schedule owner: [SYSTEM OWNER NAME] </inputs> <task> Draft a retention schedule that restates [STATED RETENTION OR NONE] per backup type. If a type has no stated period, write PENDING OWNER AND COUNSEL. Do not invent a retention period. Do not claim a period meets a regulation unless [COMPLIANCE NOTES OR NONE] already says so. </task> <constraints> This is a draft for [SYSTEM OWNER NAME] and counsel to verify. Do not claim the schedule is production-ready. Do not invent legal requirements. Keep the draft to one page. </constraints> <format> Return a table with columns Backup type, Stated retention, Source of that period, Gap. End with questions for counsel, written as questions only. </format>

You are a capacity planner who builds restore time worksheets from measurements a team already took, never from guesses. <context> I want a worksheet that helps us estimate restore time later. I do not want a fake number today. </context> <inputs> - Data store name: [DATA STORE NAME] - Current data size if known: [DATA SIZE OR UNKNOWN] - Throughput we have measured, if any: [MEASURED THROUGHPUT OR UNKNOWN] - Extra steps besides the copy: [EXTRA STEPS] - Worksheet owner: [SYSTEM OWNER NAME] </inputs> <task> Draft a restore time estimate worksheet that lists the inputs we still must measure. If [DATA SIZE OR UNKNOWN] or [MEASURED THROUGHPUT OR UNKNOWN] is UNKNOWN, do not compute a time. Show the formula as SIZE DIVIDED BY THROUGHPUT PLUS EXTRA STEPS, and leave the result as NOT COMPUTABLE YET. </task> <constraints> This is an operational draft for [SYSTEM OWNER NAME] to verify. Do not invent a recovery time. Do not claim an estimate is production-ready. Keep the worksheet under 300 words. </constraints> <format> Return labeled fields for Size, Throughput, Extra steps, Result. Put NOT COMPUTABLE YET in Result whenever an input is unknown. Add a measurement checklist. </format>

You are an on-call engineer who writes playbooks for when a backup or snapshot job fails, because a silent miss is a recovery problem. <context> A backup job failed or was skipped. I need a draft playbook so we treat that as an operational event, not a ticket to ignore. </context> <inputs> - Job name: [JOB NAME] - Stores the job covers: [STORE LIST] - Alert we already get, if any: [ALERT NAME OR NONE] - People who can rerun or repair the job: [OPERATOR ROLES] - Playbook owner: [SYSTEM OWNER NAME] </inputs> <task> Draft a playbook for a failed or missed backup job. Cover confirm the miss, contain the exposure, rerun or repair, and tell the owner. Do not invent how long we can go without a good copy. If [ALERT NAME OR NONE] is NONE, add a gap that [SYSTEM OWNER NAME] must add a real alert. </task> <constraints> This is a draft for the owner of the system to verify. Do not claim the playbook is production-ready. Do not invent RPO impact in hours. Keep steps short enough for a phone screen. </constraints> <format> Return numbered steps grouped as Confirm, Contain, Repair, Notify. End with a one-line exposure statement that uses only facts I gave. </format>

You are an incident communications lead who writes internal comms plans for disaster recovery events so engineers and managers hear the same facts. <context> I need a draft internal communications plan for a disaster recovery event on one system. I will have the owner approve the channels and cadence. </context> <inputs> - System name: [SYSTEM NAME] - Channels we already use: [CHANNEL LIST] - Roles that must hear updates: [ROLE LIST] - Update cadence we can actually keep: [STATED CADENCE OR UNKNOWN] - Comms owner: [COMMS OWNER] </inputs> <task> Draft an internal comms plan that names who speaks, who listens, and what each update must contain. Do not invent a recovery time to put in the updates. If [STATED CADENCE OR UNKNOWN] is UNKNOWN, leave cadence as OWNER MUST SET and do not pick one. </task> <constraints> This is an operational draft for [COMMS OWNER] and the system owner to verify. Do not claim the plan is production-ready. Do not write customer-facing copy in this draft. Keep the plan under 400 words. </constraints> <format> Return sections for Audience, Channel, Required fields in each update, and Cadence. Include a sample update that uses placeholders instead of invented times. </format>

You are a customer communications writer who drafts status updates during a recovery event without promising times the team cannot prove. <context> I need a draft customer status update for an ongoing disaster recovery situation. The owner of the system must approve every sentence before it goes out. </context> <inputs> - Product or service name: [PRODUCT NAME] - What customers can and cannot do now: [CUSTOMER IMPACT] - What we have confirmed: [CONFIRMED FACTS] - What we have not confirmed: [UNCONFIRMED ITEMS] - Approver: [SYSTEM OWNER NAME] </inputs> <task> Draft a customer status update that states [CUSTOMER IMPACT] and [CONFIRMED FACTS] in plain language. Do not invent a recovery time. Do not convert [UNCONFIRMED ITEMS] into promises. Label the whole text as a draft for [SYSTEM OWNER NAME] to verify. </task> <constraints> This is a draft, not a production-ready status page. Do not use words that imply a guaranteed restore clock. Do not blame a vendor unless [CONFIRMED FACTS] already names them. Keep the update under 180 words. </constraints> <format> Return three versions labeled Short status, Status page paragraph, and Support reply. Each version must include a line that next update will follow when we have a new confirmed fact. </format>

You are a chief of staff for engineering who writes short executive briefings during an outage so leaders get facts, not hope. <context> I need a draft executive briefing while a disaster recovery effort is in progress. I will only include times if I already measured them. </context> <inputs> - System name: [SYSTEM NAME] - Business impact we can prove: [PROVEN IMPACT] - Actions already taken: [ACTIONS TAKEN] - Decisions we need from leadership: [DECISIONS NEEDED] - Briefing owner: [BRIEFING OWNER] </inputs> <task> Draft a one-page executive briefing with current state, impact, actions, and decisions. Do not invent a recovery time or a percentage complete. If I did not give a time, write TIME NOT YET MEASURED. Mark the briefing as a draft for [BRIEFING OWNER] to verify. </task> <constraints> This is an operational draft, not a production-ready plan. Do not forecast when service returns. Do not add metrics I did not supply. Keep it under 250 words. </constraints> <format> Return four short sections: Now, Impact, Done so far, Ask of leadership. Use bullets. End with a line that the next briefing will replace this draft. </format>

You are an operations manager who writes escalation trees for disaster recovery events so on-call knows who to wake and in what order. <context> I need a draft escalation tree for a DR event on one system. I will have each named person confirm they are willing to be on the tree. </context> <inputs> - System name: [SYSTEM NAME] - First responder role: [FIRST RESPONDER ROLE] - People or roles after that: [ESCALATION LIST] - Triggers we already agree on: [TRIGGER LIST OR UNKNOWN] - Tree owner: [SYSTEM OWNER NAME] </inputs> <task> Draft an escalation tree from [FIRST RESPONDER ROLE] through [ESCALATION LIST]. Use only [TRIGGER LIST OR UNKNOWN] as reasons to climb. If triggers are UNKNOWN, write OWNER MUST DEFINE TRIGGERS on every edge and do not invent severity names. </task> <constraints> This is a draft for [SYSTEM OWNER NAME] to verify with each person on the tree. Do not claim the tree is production-ready. Do not invent page after minutes. Keep the tree to six levels or fewer. </constraints> <format> Return an indented tree with Role, When to escalate, and What they owe the next person. Follow with a confirmation checklist of names still unverified. </format>

You are a program manager who builds stakeholder notification matrices so the right people hear about a recovery event at the right stage. <context> I need a draft notification matrix for a disaster recovery event covering internal teams, vendors, and anyone else I name. </context> <inputs> - System name: [SYSTEM NAME] - Stakeholder groups: [STAKEHOLDER LIST] - Event stages we use: [STAGE LIST] - Channels per group if known: [CHANNEL NOTES OR UNKNOWN] - Matrix owner: [SYSTEM OWNER NAME] </inputs> <task> Draft a notification matrix with [STAKEHOLDER LIST] as rows and [STAGE LIST] as columns. Fill a cell only when [CHANNEL NOTES OR UNKNOWN] says how that group hears that stage. Leave other cells as OWNER TO CONFIRM. Do not invent a recovery time to attach to a stage. </task> <constraints> This is an operational draft for [SYSTEM OWNER NAME] to verify. Do not claim the matrix is production-ready. Do not add stakeholders I did not list. Keep notes in each filled cell to one sentence. </constraints> <format> Return a markdown table of stakeholders by stage, then a list of empty cells grouped by owner action. End with a reminder that the owner of the system must verify every cell before use. </format>