RTO (Recovery Time Objective)
Also called: recovery time objective, acceptable downtime
RTO is the maximum time you can be down before service is restored after a disaster. For PostgreSQL it breaks into parts: detecting the failure, deciding to fail over, promoting the standby (pg_promote()), and repointing clients to the new primary.
What this means
Your downtime budget, how long you can be offline before service has to be back after a disaster. For Postgres it's the sum of the steps: noticing the failure, deciding to fail over, promoting the standby, and pointing the clients at the new primary.
Why it matters operationally
Most of RTO is spent on detection and client reconnection, not the promotion itself. Knowing the breakdown tells you where to invest, fast failure detection and a quick connection-routing layer usually cut RTO more than anything inside the database.