Uptime
Active-passive
Active-passive is a standby origin that stays warm but receives no user traffic until the primary fails. A switch, automatic or manual, promotes it.
How it is measured
Measure the standby's readiness, not its existence: replication lag in seconds, the age of its last config sync, and whether a probe aimed straight at it returns 200 on a real path. A standby that has never served a request is a guess.
Then time the switch. Record the seconds from the first failed probe to the first successful user request on the standby. That interval is your real failover time, and it caps what you can honestly promise in an RTO.
Worked example
A small publisher runs a WordPress primary at a VPS host in Amsterdam and a passive copy in Toronto, synced every 15 minutes by rsync with a database replica. On Saturday the Amsterdam host loses its uplink at 06:02. The monitor needs three failed probes at 30-second spacing, then a DNS record with a 300-second TTL flips.
Visitors see errors until 06:09, seven minutes in all. The Toronto copy is missing the two posts published at 05:55 because the sync had not run yet. Nothing was broken in the plan. The plan just had a seven-minute, fifteen-minute-stale shape.
How it differs
Active-passive leaves the spare idle. Active-active keeps both sides serving. Passive costs less and avoids two writers, but excludes any proof that the spare holds up under load. Active-passive excludes shared traffic entirely, so every user lands on one box until the switch.
Common errors
Never promoting the standby in a drill. Letting config drift between the two hosts, such as PHP version, plugins, or secrets. Setting a long DNS TTL and expecting an instant switch. Forgetting the TLS certificate on the standby. Assuming the standby has the latest uploads.
In practice
Run a switch drill with a ticket and a timer. Afterwards, diff the two hosts' PHP and plugin versions and fix the drift. Drop the DNS TTL to 60 to 300 seconds before the drill and raise it only if you have a reason.