Disaster recovery planning and uptime monitoring are two sides of the same coin. DR plans specify what should happen when primary systems fail; monitoring tells you when that failure has actually occurred, confirms that failover completed successfully, and validates that recovered systems meet your recovery objectives. Without effective monitoring, a DR environment is a plan rather than a working capability — you find out it doesn't work when you need it most.
This guide covers how to monitor disaster recovery environments, detect failover events, verify automated failover with uptime monitoring, align monitoring with RTO/RPO requirements, and set up multi-region health checks that give your team the visibility needed to manage DR events effectively.
Why Monitoring Is Central to DR Strategy
The DR Plan Is a Theory; Monitoring Provides the Evidence
A disaster recovery plan defines what should happen: if the primary region fails, traffic should route to the DR region, the database replica should promote to primary, and the application should come up in the DR environment. On paper, this is a complete plan.
Monitoring answers the question: did it actually happen?
When a DR event fires, the operations team needs to know:
- Has traffic successfully routed to the DR environment?
- Is the DR environment actually serving requests?
- Are the DR region's health checks passing?
- Is the database replica promoted and accepting writes?
- Did automated failover complete, or is manual intervention required?
- What is the current response time from the DR environment?
These questions can only be answered by monitoring infrastructure that is independent of the failing primary environment. If your monitoring lives in the same region as your primary infrastructure, a regional failure takes down your monitoring alongside your application — the worst time to lose visibility.
RTO and Monitoring
Recovery Time Objective (RTO) is the maximum acceptable time between a disaster event and restoration of service. For most organizations, RTO is defined in hours or minutes — and the clock starts when the failure occurs, not when someone notices it.
Monitoring directly determines how much of your RTO budget is consumed by detection. If your monitoring tool checks every 5 minutes, and a failure happens immediately after a check, your detection time is up to 10 minutes (5 minutes to the next check, plus alert routing time). For an RTO of 15 minutes, this leaves only 5 minutes for human response and failover execution.
Monitoring granularity is therefore an RTO decision, not just an operational preference. Tighter RTOs require more frequent checks.
RPO and Monitoring
Recovery Point Objective (RPO) is the maximum acceptable data loss — how old the most recent backup or replica is allowed to be at the time of recovery. RPO is primarily a database and backup design concern, not a monitoring concern. But monitoring intersects with RPO verification: after failover, your monitoring should confirm that the recovered environment is returning current data, not stale cached responses from before the failure.
Monitoring DR Environments Directly
The Multi-Environment Monitor Architecture
Effective DR monitoring requires independent monitors for each environment:
Primary environment monitors:
- Primary application health endpoint
- Primary database TCP port
- Primary API endpoints (with response body validation)
- Primary load balancer health
- SSL certificate monitoring for primary domains
DR environment monitors (always active, not only during DR events):
- DR application health endpoint (separate URL)
- DR database TCP port
- DR API endpoints
- DR load balancer health
- SSL certificate monitoring for DR domains
Critical principle: DR environment monitors must be active at all times, not only during DR events. This ensures:
- You know the DR environment is working before you need it
- You have baseline performance data for the DR environment before failover
- You detect DR environment degradation before a primary failure forces you to fail over to a broken standby
- Failover validation is a status change in your monitoring dashboard, not a new monitoring configuration you set up under pressure
Independent Monitoring Infrastructure
Your monitoring infrastructure must be independent of both your primary and DR environments. If your monitoring runs on the same cloud provider region as your primary environment, a regional failure may take your monitoring down too.
Vigilmon operates probe nodes in geographically distributed, independent locations — not co-located with your infrastructure. When your primary region goes down, Vigilmon's probes continue checking both your primary and DR environments from outside any affected region. The monitoring system remains available to show you exactly what's failing.
Baseline the DR Environment
Before you need DR, establish baseline performance data for your DR environment:
- Typical response times from each probe region
- Expected health check response body and status codes
- Historical uptime (even passive DR environments should be tested regularly)
- Certificate expiry dates for DR domain certificates
When failover occurs, you can compare DR environment performance against this baseline rather than guessing whether slowness is "normal for DR" or indicates a problem with the DR recovery.
Detecting Failover Events
What Failover Looks Like in Monitoring Data
A failover event creates a distinctive signature in monitoring data:
-
Primary environment: HTTP checks begin failing. Response time spikes then goes to zero. Vigilmon consensus confirms: multiple probes see the primary as unreachable.
-
DR environment (if using DNS-based failover): Monitors using the production domain URL begin routing to the DR environment. Response times may increase initially as the DR environment warms up. Health checks should pass as DR comes up.
-
Recovery: Primary environment monitors begin passing again (if the primary recovers). DR environment monitors continue to pass (if traffic stays on DR while primary stabilizes).
This signature — primary down, DR picking up traffic via DNS failover — is immediately visible in a monitoring dashboard configured to show both environments.
DNS-Based Failover
Many disaster recovery architectures use DNS-based failover: the production domain's DNS record is updated to point to the DR environment's IP address or load balancer when primary fails.
For monitoring, DNS-based failover means that monitors configured with the production domain URL will automatically test whichever environment is currently serving that domain. This is both useful and important to understand:
Useful: Your user-perspective health checks automatically validate that failover is working. If the domain check passes after failover, users can reach the service.
Important to understand: Monitors using the production domain URL will not distinguish between primary and DR traffic — they see what users see. To know which environment is serving traffic, you need separate monitors for the DR environment's direct URL (not the production domain).
Monitor configuration for DNS-based failover:
- Production domain monitor:
https://app.yourcompany.com/health— validates what users experience - Primary environment direct monitor:
https://primary.internal.yourcompany.com/health— validates primary status independent of DNS - DR environment direct monitor:
https://dr.internal.yourcompany.com/health— validates DR environment status independent of DNS
When DNS failover fires, the primary direct monitor fails, the DR direct monitor passes, and the production domain monitor continues to pass — because it's now routing through DR. This three-monitor pattern tells you exactly what happened.
Active-Active vs. Active-Passive Monitoring
Active-passive DR: Primary environment serves all traffic. DR environment is on standby, warmed but not serving production traffic. Monitoring should check both environments; the DR environment checks should confirm it's healthy and ready, not serving real traffic.
Active-active (multi-region): Both environments serve production traffic. Monitoring should check each environment's health endpoint independently and alert if either region degrades. The "failover" in this case is traffic redistribution, not a binary primary/DR switch.
For active-active environments, configure per-region monitors to detect regional degradation before it becomes a full outage. If your US-East region starts returning elevated error rates, your monitoring should alert before the situation escalates to a complete failure.
Failover Detection and RTO Implications
Monitoring Check Frequency vs. RTO
The relationship between monitoring check interval and RTO:
| Check Interval | Worst-Case Detection Time | Remaining RTO Budget (1h RTO) | |---|---|---| | 1 minute | ~2 minutes (check + routing) | 58 minutes | | 5 minutes | ~7 minutes (check + routing) | 53 minutes | | 10 minutes | ~12 minutes | 48 minutes | | 30 minutes | ~32 minutes | 28 minutes | | 60 minutes | ~62 minutes | Exceeded before detection |
For organizations with RTO targets under 30 minutes, 5-minute or 1-minute monitoring check intervals are necessary to keep detection time within RTO budget.
Automated Failover Verification
If your DR architecture includes automated failover (load balancer health check triggers automatic DNS update, cloud provider failover policy, etc.), your monitoring must verify that the automation worked — not assume it did.
The verification pattern:
- Primary environment fails (monitoring detects: consensus-confirmed outage)
- Automated failover mechanism triggers (DNS update, load balancer policy, etc.)
- Monitoring continues to check production domain — should show recovery as DR environment picks up traffic
- Monitoring continues to check DR direct URL — should show DR environment healthy and serving requests
- If production domain monitor does not recover within the expected automated failover time window, alert for manual intervention
Configure a secondary alert: "Production domain has been failing for more than [automated failover timeout] minutes." This alert indicates that automated failover did not complete and human intervention is required.
Multi-Region Health Checks
Why Multi-Region Matters for DR
Single-region monitoring has a fundamental limitation for DR scenarios: a regional failure may affect the monitoring probes in the same region, creating uncertainty about whether the service is actually down or whether your monitoring is affected.
Vigilmon dispatches checks from multiple geographically distributed probe nodes. When every probe in every region confirms that the primary environment is unreachable, the conclusion is unambiguous — the failure is confirmed from multiple independent network paths and locations, not a monitoring artifact.
This multi-region confirmation is particularly important for DR decision-making. Initiating a DR failover based on a false positive (single-probe monitoring transient failure) wastes DR resources and may introduce unnecessary risk during the failover window. Vigilmon's consensus alerting ensures DR triggers are based on genuine failures confirmed by independent probes.
Geographic Coverage for DR Verification
When your DR environment is in a different geographic region than your primary, check both environments from probes that are geographically independent of both:
- Primary environment in US-East, DR environment in US-West: verify both from European and Asian probes that are unaffected by any US-specific event
- Primary in EU-West, DR in EU-Central: verify from probes in North America and Asia that are independent of EU-region disruptions
This geographic independence ensures that your monitoring can accurately report on both environments even if a regional event is causing the DR scenario in the first place.
Automated Failover Verification With Vigilmon
The Failover Verification Checklist Pattern
Configure Vigilmon monitors as the automated verification layer for your failover procedure:
Step 1 — Detect primary failure: Vigilmon consensus alert fires: primary environment is unreachable from multiple probes. Alert routes to PagerDuty.
Step 2 — Confirm with direct check: On-call engineer checks primary environment direct monitor in Vigilmon dashboard. Multiple consecutive failures confirmed — this is a genuine outage, not a transient.
Step 3 — Initiate failover: Automated failover triggers (or on-call initiates manual failover per runbook).
Step 4 — Verify DR environment is serving: On-call engineer monitors Vigilmon dashboard:
- DR environment direct URL monitor: should show passing
- Production domain monitor: should show recovery as DNS update propagates
- Response time on production domain monitor: should stabilize within expected range for DR environment
Step 5 — Confirm full recovery: Production domain monitor shows consistent passes for 10+ consecutive checks. Response time baseline has stabilized. DR environment direct URL confirms the environment is healthy.
Step 6 — Alert if failover did not complete: If production domain monitor does not recover within [automated failover SLA] minutes, secondary alert fires for manual intervention.
Heartbeat Monitors for DR Processes
Beyond HTTP health checks, heartbeat monitors verify that DR-critical background processes are running:
- Database replication heartbeat: a job that writes a test record to primary and confirms it appears on the DR replica within an expected window
- Backup verification heartbeat: a job that confirms daily backup completed and uploaded to DR storage
- DNS health check heartbeat: a job that confirms DR DNS failover policy is configured correctly (tests the failover rule without triggering it)
These heartbeat monitors detect silent failures in the DR infrastructure before they become DR failures — the worst time to discover replication is broken is when you're trying to fail over to a broken replica.
Configuring Vigilmon for DR Monitoring
Monitor Configuration Template
# Primary Environment
Monitor: app-primary-health
URL: https://primary.yourcompany.com/health
Type: HTTP
Interval: 1 minute
Expected status: 200
Expected body contains: "status":"ok"
Alert: PagerDuty P1
Monitor: app-primary-db-port
URL: tcp://primary-db.yourcompany.com:5432
Type: TCP
Interval: 1 minute
Alert: PagerDuty P1
# DR Environment (always active)
Monitor: app-dr-health
URL: https://dr.yourcompany.com/health
Type: HTTP
Interval: 5 minutes
Expected status: 200
Expected body contains: "status":"ok"
Alert: Slack #dr-monitoring (no overnight page unless primary is also down)
Monitor: app-dr-db-port
URL: tcp://dr-db.yourcompany.com:5432
Type: TCP
Interval: 5 minutes
Alert: Slack #dr-monitoring
# Production Domain (user-perspective)
Monitor: app-production-domain
URL: https://app.yourcompany.com/health
Type: HTTP
Interval: 1 minute
Expected status: 200
Alert: PagerDuty P1 (this is what users experience)
# SSL Certificates
Monitor: ssl-primary-domain
URL: https://yourcompany.com
Type: SSL
Alert at 30 days: Jira ticket
Alert at 14 days: Slack + Jira escalation
Alert at 7 days: PagerDuty P1
Monitor: ssl-dr-domain
URL: https://dr.yourcompany.com
Type: SSL
Alert at 30 days: Jira ticket
Alert Routing for DR Scenarios
Route DR alerts to reflect the severity of the situation:
Primary environment DOWN (consensus confirmed)
→ PagerDuty P1 immediately
→ Slack #incidents
→ DR runbook link in alert message
DR environment DOWN (while primary is up)
→ Slack #dr-monitoring
→ Jira ticket for DR environment investigation
→ No overnight page (DR is standby — primary is serving users)
DR environment DOWN (while primary is also down)
→ PagerDuty P1 escalation (DR is supposed to be handling failover)
→ Escalate immediately — both environments failing is a full outage
Production domain DOWN for more than [failover SLA] minutes
→ PagerDuty P1 escalation
→ Automated failover may have failed; manual intervention required
Database replication heartbeat MISSING
→ Slack #dr-monitoring
→ Jira ticket: investigate replication lag or failure
→ Escalate to DBA within 2 hours
DR Monitoring Maturity Levels
Level 1: Basic DR Detection
- Primary environment HTTP health check (1-minute interval)
- PagerDuty alert on primary failure
- No DR environment monitoring
Gap: You know the primary is down, but you have no visibility into whether DR is ready or whether failover succeeded.
Level 2: DR Readiness Visibility
- Primary environment HTTP health check (1-minute interval)
- DR environment HTTP health check (5-minute interval, always active)
- Production domain health check (1-minute interval)
- Alert if DR environment is degraded while primary is healthy
Gap: You can see DR environment status, but no automated failover verification or heartbeat monitoring for DR processes.
Level 3: Full DR Monitoring
- Primary environment HTTP + TCP checks (1-minute interval)
- DR environment HTTP + TCP checks (5-minute interval, always active)
- Production domain check (1-minute interval, tracks what users experience)
- SSL certificate monitoring for all domains (30/14/7-day alerts)
- Heartbeat monitors for replication health, backup jobs, DNS failover health
- Alert escalation if production domain fails for more than [automated failover SLA] minutes
- Documented failover verification checklist using monitoring dashboard as the verification layer
This is the target state. Full DR monitoring gives you detection, verification, and confidence that your DR capability is working before you need it.
DR Monitoring Quick Reference
Monitor configuration:
- [ ] Primary environment: 1-minute HTTP health check + critical TCP ports
- [ ] DR environment: 5-minute HTTP health check + TCP ports (always active, not DR-only)
- [ ] Production domain: 1-minute HTTP health check (user-perspective)
- [ ] SSL certificates for primary and DR domains
- [ ] Separate monitors for primary direct URL, DR direct URL, and production domain
Failover verification:
- [ ] DR environment monitor passes after failover (DR environment is healthy)
- [ ] Production domain monitor recovers after DNS propagation (users can reach service)
- [ ] Response time on production domain stabilizes within expected range
- [ ] Secondary alert configured: production domain down for more than [failover SLA] minutes → manual intervention required
DR environment health:
- [ ] DR environment monitors run continuously, not only during DR events
- [ ] Baseline response times documented for DR environment
- [ ] Heartbeat monitors for replication health and backup jobs
- [ ] DR SSL certificates monitored independently of primary SSL certificates
RTO alignment:
- [ ] Check interval matches RTO budget (1-minute for RTOs under 15 minutes)
- [ ] Alert routing delivers page within 2 minutes of consensus confirmation
- [ ] On-call has dashboard access showing primary and DR environment status simultaneously
Conclusion
Disaster recovery monitoring is not a post-DR-event concern — it's a continuous operational requirement. DR environments that are not monitored before they're needed are plans, not capabilities. Failover procedures that don't include monitoring-based verification are hopes, not confirmations.
The monitoring architecture for DR — independent probe nodes, separate monitors for primary and DR environments, production domain checks for user-perspective validation, heartbeat monitors for replication and backup health — gives operations teams the visibility to detect failures immediately, verify failover completion with confidence, and meet RTO targets that manual discovery would otherwise blow through.
Vigilmon's multi-region consensus alerting is particularly valuable in DR scenarios: every alert represents a genuine failure confirmed by geographically independent probes, ensuring DR failover decisions are based on real failures rather than single-probe false positives.
Try Vigilmon free at vigilmon.online — no agents, multi-region consensus alerting, SSL monitoring, heartbeat monitoring for DR processes, and up to 5 monitors permanently free with no credit card required.
Tags: #monitoring #disasterrecovery #failover #rto #rpo #uptime #multiregion #vigilmon #devops #sre #2026