Databases
AuraScore 91/100

Grid Outage Management Database Failover Verification Checklist

Verify cross-region replication, failover automation, and data consistency for critical Outage Management System (OMS) databases.

Run this checklist before executing disaster recovery drills or upgrading high-availability configurations for electrical grid outage management databases. It validates replication lag, split-brain safeguards, and rapid service restoration capabilities.

Template

Role: Senior Reliability Systems Database Engineer responsible for mission-critical electrical distribution and OMS infrastructure.

Context

  • OMS Database Platform: {{oms_database_engine}}
  • Target RPO: {{rpo_target_seconds}}
  • Target RTO: {{rto_target_minutes}}
  • Secondary Standby Region: {{secondary_cluster_region}}
  • Drill Maintenance Window: {{dr_test_window_hours}}
  • Dependent Grid Services: {{critical_grid_services}}

Task

Author a high-availability and disaster recovery verification checklist that grid operations engineers must execute to validate failover readiness, quorum consistency, and health telemetry for the {{oms_database_engine}} cluster supporting {{critical_grid_services}}.

Method

  1. Establish baseline replication latency measurements between primary nodes and {{secondary_cluster_region}}.
  2. Verify health-check thresholds and automatic quorum failover triggers to prevent split-brain scenarios.
  3. Validate write-ahead log shipping and transaction replay rates to guarantee RPO within {{rpo_target_seconds}}.
  4. Design connection pool rerouting and DNS switchover tests against {{critical_grid_services}} within {{rto_target_minutes}}.
  5. Audit read-only standby accessibility for dispatch consoles during failover transition states.
  6. Formulate fallback procedures to safely re-establish primary-replica sync without data loss if failover is aborted.
  7. Structure pre-flight, failover execution, and post-restoration audit checks within {{dr_test_window_hours}}.

Constraints

  • Failover steps MUST include an explicit RPO validation check against {{rpo_target_seconds}}.
  • Failover execution steps MUST NOT disrupt offline dispatcher caches if database reconnection exceeds {{rto_target_minutes}}.
  • The checklist MUST specify exact verification commands or log indicators for {{oms_database_engine}}.
  • Output MUST format every step using markdown checkboxes - [ ] with explicit step sequencing.

Output format

Provide the review formatted as three sequential checklist sections:

  1. Pre-Failover Health & Replication Checks (4-5 checklist items)
  2. Execution & Cluster Promotion Steps (4-5 checklist items)
  3. Post-Promotion Verification & Grid Service Reconnection (4-5 checklist items) Each item must use this format: - [ ] [Step #] Action | Expected Result: <measurable state>.

Self-review

  • Ensure all variables ({{oms_database_engine}}, {{rpo_target_seconds}}, {{rto_target_minutes}}, {{secondary_cluster_region}}, {{dr_test_window_hours}}, {{critical_grid_services}}) are present.
  • Verify all checklist items contain actionable instructions and measurable success criteria.
  • Confirm there are no markdown syntax errors or generic filler phrases.
AuraScore breakdown
91/100Provisional
Instruction clarity15/15 · Strong

Explicit role, a named task, and discrete steps the model can follow.

Context architecture12/12 · Strong

Background, inputs and variables the model needs before it starts.

Constraint engineering12/12 · Strong

Hard boundaries — what the model must and must not do.

Output specification14/14 · Strong

A named, field-level shape for the response.

Reasoning structure10/10 · Strong

Ordered work items that force analysis before an answer.

Model compatibility10/10 · Strong

Length and structure that travel across frontier models.

Token efficiency5/10 · Thin

Signal density — instruction weight without padding.

Reusability7/7 · Strong

Documented variables so the scaffold adapts to new inputs.

Robustness5/5 · Strong

Quality bar, assumptions and behaviour when inputs are thin.

Observed performance1/5 · Thin

How much real usage the template has behind it.

developers
developers-databases
energy-utilities
disaster-recovery
high-availability
oms