Automatic vs Manual Failover: The Foundational Choice - Failover Strategies | OneNoughtOne

0/273

System Design (HLD)Failover Strategies

Failover Strategies: Building Resilient Systems

LevelAdvanced

Duration90 mins

TopicFailover Strategies

1 / 5

Automatic vs Manual Failover: The Foundational Choice

The Moment Everything Changes

It's 3:47 AM. Your primary database server has just failed. Thousands of users are seeing error pages. Revenue is bleeding at $10,000 per minute. The standby server is ready and waiting, perfectly synchronized. One fundamental question remains: Should a computer or a human decide to switch over?

This is not an abstract architectural debate—it's a decision that will determine how quickly your system recovers, whether you avoid data loss, and quite possibly whether your company survives. The choice between automatic and manual failover represents one of the most consequential decisions in high-availability system design.

Get it right, and failures become invisible blips. Get it wrong, and you'll face either extended outages (waiting for humans) or cascading disasters (from premature automated switches). This page provides the comprehensive framework you need to make this choice correctly for your specific context.

What You Will Learn

By the end of this page, you will deeply understand: the core differences between automatic and manual failover, when each approach is appropriate, hybrid strategies that combine both, implementation patterns used in production systems, and the decision framework that Principal Engineers use to make this architectural choice.

Understanding Failover Fundamentals

Before comparing automatic and manual failover, we must establish a precise understanding of what failover actually means in distributed systems architecture.

Failover Defined:

Failover is the process of switching from a failed primary component to a redundant or standby component to maintain system availability. This simple definition masks enormous complexity: How do we know the primary has failed? What state needs to be preserved? How do we redirect traffic? What happens to in-flight transactions?

Failover exists because no component in a distributed system is perfectly reliable. Hardware fails. Software crashes. Networks partition. The question is never if failover will be needed, but when and how.

Components of a Failover System

•Primary (Active) Component — The component currently serving production traffic and maintaining authoritative state. This might be a database, application server, load balancer, or any critical system element.
•Standby (Passive/Secondary) Component — One or more components ready to assume the primary role. These may be fully synchronized (hot standby), partially synchronized (warm standby), or completely cold (cold standby).
•Health Detection System — The mechanism that determines whether the primary component is functioning correctly. This might use heartbeats, synthetic transactions, resource monitoring, or a combination.
•Failover Decision Logic — The brain that decides when to trigger failover based on health detection signals. This is where automatic vs manual comes into play.
•Traffic Routing Mechanism — The infrastructure that directs traffic from the failed primary to the new primary (DNS, load balancers, floating IPs, connection managers).
•State Synchronization System — The mechanism that ensures the standby has sufficient state to take over without data loss or inconsistency.

The Failover Paradox

Here's a subtle but critical insight: Every component of the failover system is itself subject to failure. Your health detection might fail. Your failover logic might crash. Your routing mechanism might be unreachable. Designing failover systems requires recursive thinking about what happens when the failover itself fails.

Automatic Failover: Deep Dive

Automatic failover occurs when the system detects a failure and initiates the switch to a standby component without human intervention. The entire process—detection, decision, and execution—happens programmatically, typically completing in seconds to minutes.

The Promise of Automatic Failover:

Automatic failover offers compelling benefits that make it the default choice for many high-availability architectures:

1. Speed of Recovery

Human reaction time cannot compete with automated systems. Consider the timeline of a typical manual failover:

5-15 minutes: Alert fires and reaches on-call engineer
2-10 minutes: Engineer wakes up, acknowledges alert
5-20 minutes: Engineer investigates, confirms genuine failure
5-30 minutes: Engineer executes failover procedure
2-10 minutes: Verification that failover succeeded

Total: 20-85 minutes of downtime

Automatic failover can complete the same process in 10-120 seconds, representing a 10x-500x improvement in recovery time.

Automatic Failover Timeline Breakdown
Phase	Duration	Description
Failure Detection	5-30 seconds	Health checks detect anomaly, wait for confirmation
Decision & Validation	1-5 seconds	System verifies failure, checks prerequisites
Standby Promotion	1-30 seconds	Standby assumes primary role, completes any sync
Traffic Redirect	5-60 seconds	DNS/LB/connection routing switches to new primary
Total Recovery	12-125 seconds	Full availability restoration

2. Consistency in Execution

Automated systems execute the same procedure identically every time. There's no variation based on whether the on-call engineer is experienced or junior, well-rested or exhausted, familiar with this specific system or not.

This consistency eliminates entire categories of human error:

Forgotten steps in the failover procedure
Typos in commands or configurations
Wrong order of operations
Panic-induced mistakes under pressure

3. 24/7 Coverage Without Human Cost

Automatic failover works at 3 AM on holidays just as reliably as at 2 PM on Tuesday. It doesn't require staffing on-call rotations with engineers capable of executing complex failover procedures. This represents significant operational cost savings and reduced burnout.

The Dark Side of Automation

Automatic failover can also automatically cause disasters. A misconfigured health check might trigger unnecessary failovers. A network partition might cause both nodes to believe they're primary (split-brain). Cascading failovers can overwhelm standby systems. The same speed that makes automatic failover valuable can propagate mistakes before humans can intervene.

Automatic Failover Architecture Patterns:

Pattern 1: Leader Election with Consensus

Used in systems like ZooKeeper, etcd, and Consul. Multiple nodes participate in a consensus protocol (Raft, Paxos) to elect a leader. When the leader fails, remaining nodes automatically elect a new leader. This approach is highly robust but adds complexity.

Pattern 2: Health-Check Triggered Promotion

A monitoring system continuously checks the primary. When failures exceed a threshold, the system automatically promotes the standby and updates routing. This is common in database failover (PostgreSQL with Patroni, Redis Sentinel).

Pattern 3: Floating Virtual IP (VIP)

The primary holds a virtual IP address. Failover involves migrating this VIP to the standby. Clients continue connecting to the same IP without reconfiguration. Common in traditional enterprise setups (Keepalived, Pacemaker).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
interface HealthCheckResult {
  isHealthy: boolean;
  latency: number;
  timestamp: Date;
  details: string;
}
 
interface FailoverConfig {
  failureThreshold: number;      // Consecutive failures before failover
  checkInterval: number;         // Milliseconds between health checks
  failoverTimeout: number;       // Max time for failover completion
  requireQuorum: boolean;        // Require multiple observers to agree
}
 
class AutomaticFailoverController {
  private consecutiveFailures: number = 0;
  private failoverInProgress: boolean = false;
  
  constructor(
    private primary: Node,
    private standby: Node,
    private config: FailoverConfig,
    private observers: Observer[]  // Multiple vantage points
  ) {}
 
  async checkAndFailover(): Promise<void> {
    // Perform health check from this controller's perspective
    const healthResult = await this.checkHealth(this.primary);
    
    if (healthResult.isHealthy) {
      this.consecutiveFailures = 0;
      return;
    }
    
    this.consecutiveFailures++;
    console.log(`Primary failure detected: ${this.consecutiveFailures}/${this.config.failureThreshold}`);
    
    // Don't trigger on single failure - wait for threshold
    if (this.consecutiveFailures < this.config.failureThreshold) {
      return;
    }
    
    // Require quorum agreement to prevent split-brain
    if (this.config.requireQuorum) {
      const quorumResult = await this.checkQuorum();
      if (!quorumResult.quorumReached) {
        console.log('Quorum not reached - deferring failover decision');
        return;
      }
    }
    
    // Prevent duplicate failover attempts
    if (this.failoverInProgress) {
      return;
    }
    
    // Execute automatic failover
    await this.executeFailover();
  }
 
  private async checkQuorum(): Promise<{ quorumReached: boolean; votes: number }> {
    const votes = await Promise.all(
      this.observers.map(o => o.isPrimaryHealthy(this.primary))
    );
    const unhealthyVotes = votes.filter(v => !v).length;
    const quorumRequired = Math.floor(this.observers.length / 2) + 1;
    
    return {
      quorumReached: unhealthyVotes >= quorumRequired,
      votes: unhealthyVotes
    };
  }
 
  private async executeFailover(): Promise<void> {
    this.failoverInProgress = true;
    console.log('Initiating automatic failover...');
    
    try {
      // Step 1: Fence the old primary (prevent split-brain writes)
      await this.fencePrimary(this.primary);
      
      // Step 2: Ensure standby is caught up
      await this.waitForStandbySync(this.standby);
      
      // Step 3: Promote standby to primary
      await this.promoteStandby(this.standby);
      
      // Step 4: Update routing (DNS, load balancer, etc.)
      await this.updateRouting(this.standby);
      
      // Step 5: Verify new primary is serving traffic
      await this.verifyNewPrimary(this.standby);
      
      console.log('Automatic failover completed successfully');
    } catch (error) {
      console.error('Failover failed - alerting for manual intervention', error);
      await this.alertOnCall(error);
    } finally {
      this.failoverInProgress = false;
    }
  }
}

Manual Failover: Deep Dive

Manual failover requires human intervention to initiate the switch from primary to standby. The system may detect failures automatically and alert operators, but the decision to failover and its execution remain under human control.

Why Would Anyone Choose Manual Failover?

Given the speed advantages of automatic failover, it might seem irrational to ever choose manual intervention. Yet many of the most critical systems in the world—banking core systems, air traffic control, nuclear plant operations—rely heavily on manual failover. Here's why:

Advantages of Manual Failover

•Human Judgment in Ambiguous Situations — Not all failures are clear-cut. Sometimes a database appears unresponsive because of a slow query, not a crash. A human can investigate, determine the root cause, and often resolve the issue faster than failover would complete.
•Prevention of Cascade Failures — Automatic failover can create avalanche effects. If the primary failed due to load, automatically shifting that load to a standby might cause it to fail too. Humans can implement throttling or load shedding before failover.
•Data Integrity Assurance — Some failures leave data in ambiguous states. A human can verify replication status, check for in-flight transactions, and ensure no data will be lost before committing to failover.
•Coordination Across Systems — Complex architectures have interdependencies. Failing over a database without adjusting application server connections might cause more problems. Humans can orchestrate across systems.
•Regulatory and Compliance Requirements — Some industries require human oversight for critical system changes. Financial services, healthcare, and government systems often mandate manual approval for failover events.

The True Cost of Downtime Calculation:

The decision between automatic and manual failover often comes down to a calculation that many organizations get wrong. They compare:

Cost of extended downtime (manual) vs.
Cost of unnecessary/problematic failovers (automatic)

But the calculation is more nuanced:

Expected Cost (Manual) = P(real failure) × Duration(manual failover) × Cost(per minute) + P(false positive) × Duration(investigation) × Cost(engineering time)

Expected Cost (Automatic) = P(real failure) × Duration(automatic failover) × Cost(per minute) + P(false positive) × P(unnecessary failover causes issues) × Cost(issues) + P(split-brain) × Cost(data corruption)

The presence of catastrophic tail risks (data corruption, split-brain) in the automatic equation is why conservative systems prefer manual failover despite higher average downtime.

The Experience Factor

Organizations with mature operations teams and well-documented runbooks can execute manual failover surprisingly quickly. With practice, a well-drilled team can complete failover in 5-10 minutes—still slower than automatic, but fast enough that the risk-reduction benefits of human judgment outweigh the time cost.

Manual Failover Workflow:

A well-designed manual failover process follows a structured workflow that minimizes human error while leveraging human judgment:

Phase 1: Detection & Alerting

Automated monitoring detects anomaly
Alert fires to on-call engineer
Engineer acknowledges and begins investigation

Phase 2: Investigation & Decision

Engineer verifies genuine failure vs false positive
Checks replication lag and data consistency
Evaluates whether failover is necessary or if another resolution is possible
Obtains approval if required by policy

Phase 3: Preparation

Notifies stakeholders of impending failover
Verifies standby is ready to assume primary role
Prepares rollback plan if failover fails

Phase 4: Execution

Follows documented runbook step-by-step
Uses automation where possible for individual steps
Verifies each step before proceeding

Phase 5: Verification

Confirms new primary is serving traffic correctly
Validates data integrity
Updates monitoring and documentation

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
# Database Failover Runbook
## Pre-Failover Checklist
 
### 1. Verify Genuine Failure (5 min)
- [ ] Check primary connectivity from multiple locations
- [ ] Review recent error logs: `kubectl logs -n db primary-0 --tail=100`
- [ ] Verify not a monitoring false positive: `ping <primary-ip>`
- [ ] Check for ongoing maintenance or known issues in #incidents
 
### 2. Assess Standby Readiness (3 min)
- [ ] Verify standby is online: `kubectl get pod standby-0 -n db`
- [ ] Check replication lag: `SELECT pg_last_wal_replay_lsn() - pg_last_wal_receive_lsn()`
- [ ] Confirm < 1MB lag before proceeding
- [ ] Verify standby has sufficient resources
 
### 3. Obtain Approval (if required)
- [ ] Page: @database-lead
- [ ] Approval received: _____________ (name/time)
 
## Failover Execution
 
### 4. Fence Primary (2 min)
```bash
# Prevent writes to old primary to avoid split-brain
kubectl exec primary-0 -n db -- pg_ctl stop -m fast
kubectl delete pvc primary-data -n db  # Prevents restart with old data
```
 
### 5. Promote Standby (2 min)
```bash
kubectl exec standby-0 -n db -- pg_ctl promote
# Wait for promotion confirmation
kubectl exec standby-0 -n db -- psql -c "SELECT pg_is_in_recovery()"
# Should return 'f' (false) indicating primary mode
```
 
### 6. Update Routing (3 min)
```bash
# Update Kubernetes service to point to new primary
kubectl patch svc db-primary -n db -p '{"spec":{"selector":{"role":"primary"}}}'
kubectl label pod standby-0 -n db role=primary
```
 
### 7. Application Verification (5 min)
- [ ] Health check endpoints returning 200
- [ ] Test write query succeeds
- [ ] Verify connection pools reconnected
- [ ] Monitor error rates returning to baseline
 
## Post-Failover
 
### 8. Documentation
- [ ] Update runbook with lessons learned
- [ ] Create incident ticket
- [ ] Schedule post-mortem if warranted
 
**Total Expected Time: 20-30 minutes**

Hybrid Approaches: The Best of Both Worlds

In practice, the most sophisticated high-availability systems don't choose strictly between automatic and manual failover. They implement hybrid approaches that leverage the strengths of both while mitigating their weaknesses.

Pattern 1: Automatic Detection, Human Approval

The system automatically detects failures and prepares for failover, but pauses at a decision point requiring human approval. This captures the speed of automated detection and preparation while preserving human judgment for the commit decision.

This pattern is ideal when:

Detection is straightforward but consequences of failover are significant
Regulatory requirements mandate human oversight
False positives are common but real failures are rare
Engineering team has reliable 24/7 coverage

Automated Stages

•Health check monitoring
•Failure detection
•Alert generation
•Standby health verification
•Replication lag check
•Pre-failover preparation

Human Decision Points

•Confirm genuine failure
•Approve failover initiation
•Select failover target (if multiple)
•Coordinate with dependent teams
•Verify post-failover success
•Initiate rollback if needed

Pattern 2: Time-Delayed Automatic Failover

Automatic failover is configured with a significant delay (e.g., 15-30 minutes). If no human intervenes during the delay, failover proceeds automatically. This provides a window for human judgment while ensuring eventual recovery even if no human is available.

Pattern 3: Tiered Failover Based on Failure Type

Different failure types trigger different failover modes:

Complete unavailability → Automatic failover (clear-cut, no ambiguity)
Degraded performance → Alert for human decision (might recover)
Data corruption detected → Block automatic failover, require human review
Network partition → Escalate to senior engineer (complex decision)

Failover Mode by Failure Signature
Failure Type	Confidence Level	Recommended Mode	Rationale
Process crash (confirmed dead)	Very High	Automatic	No ambiguity, fast recovery valuable
Timeout on health checks	Medium	Delayed Automatic	Might be transient, wait briefly
Elevated error rates	Low	Manual	Could be upstream issue, not primary failure
Replication lag growing	Low	Manual	Usually self-recovers, failover might cause data loss
Network partition detected	N/A	Senior Escalation	Split-brain risk, complex judgment needed

Pattern 4: Automatic Failover with Automatic Rollback

The system automatically fails over, but continuously monitors the new primary. If the failover causes problems (new primary also struggling), it can automatically rollback or escalate to humans. This provides fast recovery while limiting blast radius of bad failover decisions.

This requires sophisticated monitoring that can distinguish between:

Expected post-failover conditions (reconnection storms, cache warming)
Genuine problems with the new primary
Problems that indicate the original failover was unnecessary

Complexity Cost

Hybrid approaches add significant complexity. The conditional logic for choosing between automatic and manual paths can itself become a source of bugs. Each pattern requires extensive testing, and operators must understand the current mode. Don't implement hybrid approaches unless you have the operational maturity to manage them.

The Decision Framework

How do Principal Engineers actually decide between automatic and manual failover for a given system? Here's the decision framework used in production environments:

Factor 1: Cost of Downtime vs Cost of Bad Failover

This is the fundamental tradeoff. Quantify both:

Downtime Cost: Revenue lost per minute, user impact, SLA penalties, reputation damage

Bad Failover Cost: Data loss/corruption recovery, split-brain resolution, customer trust, engineering time

If downtime cost vastly exceeds bad-failover cost → automatic If bad-failover cost can be catastrophic → manual with fast execution

Key Decision Questions

•Can we detect failures reliably? — High false-positive rates favor manual (humans filter noise). High detection accuracy enables automatic.
•Is the standby reliably synchronized? — Synchronous replication enables automatic. Async with lag requires human verification.
•What happens if both nodes think they're primary? — If split-brain causes data corruption, favor manual. If idempotent operations make it recoverable, automatic is safer.
•How quickly can humans respond? — 5-minute response time makes manual viable. 30-minute response time may mandate automatic.
•What's the regulatory environment? — Healthcare, finance, and government often require human approval regardless of technical capabilities.
•How frequently do failures occur? — Frequent failures with fast automatic recovery can provide better uptime than rare failures with slow manual recovery.

Factor 2: System Characteristics

Stateless Services: Strong candidate for automatic failover. No data to corrupt, load balancers can simply route elsewhere. Risk is minimal.

Stateful Services with Synchronous Replication: Good candidate for automatic failover. Data is consistent, no risk of data loss.

Stateful Services with Asynchronous Replication: Caution with automatic failover. Must quantify acceptable data loss (RPO) and ensure automatic failover respects this.

Services with Complex Dependencies: Manual failover preferred. Human can coordinate across interdependent systems.

Factor 3: Operational Maturity

Automatic failover requires operational readiness:

Comprehensive monitoring that can accurately detect failures
Tested failover automation that works reliably
Runbooks for diagnosing automatic failover problems
Team capability to debug post-automatic-failover issues

Failover Mode Selection Matrix
Scenario	Recommendation	Key Considerations
Stateless API behind load balancer	Automatic	Low risk, fast recovery, no data concerns
Primary-replica database (sync repl)	Automatic with safeguards	Ensure quorum, fencing of old primary
Primary-replica database (async repl)	Manual or delayed automatic	Verify replication lag acceptable
Distributed database cluster	Consensus-based automatic	Raft/Paxos handles leader election
Legacy system with manual state	Manual only	Too complex for reliable automation
Multi-region primary	Manual with automation assist	Human judgment for regional decisions

Start with Manual, Evolve to Automatic

For new systems, consider starting with manual failover and evolving to automatic as you gain confidence. This approach lets you: understand failure modes first-hand, refine detection thresholds based on real incidents, build team expertise before automating, progressively reduce human involvement as trust grows.

Implementation Considerations

Regardless of whether you choose automatic or manual failover, certain implementation principles apply universally:

Principle 1: Test Failover Regularly

Failover that's never tested is failover that won't work when needed. Both automatic and manual failover must be exercised regularly:

Automatic: Run scheduled failover drills, verify recovery time meets targets
Manual: Practice runbook execution, time your team's response

At Netflix, deliberate chaos (Chaos Monkey) ensures failover is constantly exercised. At Google, regular 'DiRT' (Disaster Recovery Testing) drills validate manual procedures.

Critical Implementation Requirements

•Fencing/STONITH (Shoot The Other Node In The Head) — Before promoting standby, ensure old primary cannot continue writing. This prevents split-brain. Methods include: power fencing (cut power to old primary), network fencing (block all traffic), application fencing (revoke credentials).
•Idempotent Failover Operations — Failover procedures should be safe to run multiple times. If failover partially completes and is re-run, it shouldn't cause additional damage.
•Observability Throughout — Log every step of failover with unique correlation IDs. Emit metrics for failover duration, success rate, and causes. This data is essential for improvement.
•Graceful Client Handling — Applications should handle failover transparently where possible. Connection retry logic, circuit breakers, and connection pool refresh are essential.
•Rollback Capability — Every failover plan needs a rollback plan. What if the standby fails worse than the primary? How do you restore the original primary safely?

Principle 2: Avoid Failover Loops

A dangerous anti-pattern is a system that fails over, determines the new primary is unhealthy, fails back, determines the original is unhealthy, and loops. Implement protections:

Minimum time between failovers (e.g., 10 minutes)
Maximum failovers per time window (e.g., 3 per hour)
Escalation to humans after repeated failovers

Principle 3: Document Everything

Both automatic and manual failover require extensive documentation:

Architecture diagrams showing primary, standby, and failover paths
Configuration parameters and their meanings
Expected behavior during failover
Troubleshooting guides for common issues
Post-failover verification procedures

The Human Factor in Automation

Even with fully automatic failover, humans remain critical. They design the automation, set the parameters, review the outcomes, and intervene when automation fails. The goal isn't to remove humans from the loop—it's to let humans work at the strategic level while automation handles tactical execution.

Real-World Examples

Let's examine how major systems implement their failover decisions:

Amazon RDS Multi-AZ: Automatic Failover

Amazon RDS with Multi-AZ automatically fails over when it detects:

Loss of availability in the primary AZ
Loss of network connectivity to primary
Compute unit failure on primary
Storage failure on primary

Failover typically completes in 60-120 seconds. RDS uses synchronous replication to the standby, ensuring no data loss. The DNS endpoint automatically updates to point to the new primary. This is a textbook case where automatic failover is appropriate: reliable detection, synchronous replication, and managed fencing.

PostgreSQL with Patroni: Configurable Automatic

Patroni is a template for PostgreSQL HA that uses etcd/ZooKeeper/Consul for consensus. It supports automatic failover with extensive configuration:

ttl: How long before a lost leader is considered dead
loop_wait: How frequently to check health
retry_timeout: How long to wait before giving up on failed operations
maximum_lag_on_failover: Maximum replication lag acceptable for promotion

Operators can tune these parameters for their risk tolerance. Conservative settings (longer TTL, lower max lag) favor data safety. Aggressive settings favor recovery speed.

Financial Trading Systems: Manual Failover

Major stock exchanges and trading platforms typically use manual failover for core matching engines:

The cost of a false failover (trading interruption, order book confusion) is extremely high
Regulatory scrutiny requires audit trails of human decisions
Recovery time of a few minutes is acceptable compared to risk of automated mistakes
Engineers are always on standby during market hours

These systems invest heavily in fast manual procedures: one-click failover consoles, pre-validated runbooks, and regular drills.

Google Spanner: Consensus-Based Automatic

Spanner uses Paxos consensus groups for data replication. Leader election is automatic—if a leader fails, remaining replicas elect a new leader through the consensus protocol. This is automatic failover without the typical risks because:

Consensus protocol guarantees no split-brain
Synchronous replication guarantees no data loss
Multiple replicas provide no single point of failure
Leader election is proven mathematically correct

The Pattern Across Examples

Notice the pattern: systems choose automatic failover when they have strong guarantees (synchronous replication, consensus protocols) that eliminate the risks of split-brain and data loss. When those guarantees are absent, conservative systems favor human judgment.

Summary: Automatic vs Manual Failover

The choice between automatic and manual failover is not a technical preference—it's a calculated decision balancing speed, risk, and organizational capability. Let's consolidate the key insights:

Key Takeaways

•Automatic failover provides faster recovery but carries risk of cascading failures, split-brain, and amplifying problems. Best suited for stateless services and systems with strong consistency guarantees.
•Manual failover preserves human judgment for complex decisions but extends downtime. Best suited for high-stakes systems where wrong failover is worse than delayed failover.
•Hybrid approaches combine automated detection with human decision points, capturing benefits of both while adding implementation complexity.
•The right choice depends on: detection reliability, replication mode, split-brain consequences, human response capability, and regulatory requirements.
•Both modes require: regular testing, comprehensive observability, proper fencing, and well-documented procedures.
•Evolution path: Start manual to learn failure modes, progressively automate as confidence grows.

What's Next:

With the automatic vs manual decision framework established, we turn to the critical question of how failures are detected in the first place. The next page explores failover detection mechanisms—heartbeats, health checks, synthetic monitoring, and the subtle art of distinguishing genuine failures from transient issues.

Page Complete

You now understand the fundamental tradeoffs between automatic and manual failover, can apply the decision framework to real systems, and recognize hybrid patterns used in production. Next, we'll examine failover detection—the first and most critical step in any failover process.