MTTR vs RTO

Warm standby vs hot standby — what's the actual difference#

Both have a replica running on a separate machine, continuously syncing with the primary. The difference is what that replica is doing while it waits.

Hot standby — the replica is live and actively serving read traffic. Failover is automated: a health check detects the primary is dead and promotes the replica within seconds. No human involved.

Primary  ──writes──▶  Replica (serving reads, fully synced)

Primary dies at 3:00:00
Health check fires  at 3:00:05
Replica promoted    at 3:00:08
Traffic redirected  at 3:00:10
RTO = ~10 seconds

Warm standby — the replica is running and staying in sync, but serving no traffic. It's just sitting there replicating. When the primary dies, someone (or a script) has to manually promote it, update the load balancer config, run health checks, and verify it's ready. That process takes minutes.

Primary  ──writes──▶  Replica (syncing, idle — serving nothing)

Primary dies at 3:00:00
Engineer gets paged  at 3:02:00
Promotes replica,
updates config       at 3:08:00
RTO = ~8 minutes

The hidden cost of RPO = 0#

RPO = 0 means zero data loss — every write must be confirmed on the replica before the user gets a response. That's synchronous replication.

Synchronous replication adds latency to every write. The write has to travel to the replica and get confirmed before the user gets a response. If the replica is in another datacenter, that's 50–100ms added to every single write operation.

Async replication (RPO = seconds):
User writes → Primary confirms → User gets response ✓
                ↓ (background)
            Replica replicates

Sync replication (RPO = 0):
User writes → Primary writes → Replica writes → Both confirm → User gets response ✓
              ←————————— 50–100ms round trip if cross-datacenter ————————————→

This is why most systems use asynchronous replication — slightly higher RPO (seconds of potential data loss), but no latency penalty on writes. The business decides which trade-off is acceptable.

How they drive architecture decisions#

MTTR vs RTO — they sound similar but are different things#

• MTTR — what actually happens on average when things break. A measurement of past incidents.
• RTO — what the business requires as the maximum acceptable downtime. A target you design to.

You design your system so that MTTR stays below RTO. If your RTO is 30 minutes, your recovery process — detection, failover, verification — must consistently complete in under 30 minutes.

RTO = 30 min  (the ceiling the business set)
MTTR = 8 min  (what actually happens based on incident history)

→ You have headroom. You're meeting the SLA comfortably.

If MTTR creeps up to 35 min → you're breaching RTO → time to improve your recovery process.