The short answer
RTO and RPO describe two different kinds of pain. RTO, the recovery time objective, is how long a service can stay down before the business feels it. RPO, the recovery point objective, is how much data you can lose, counted backwards in time from the failure. A four hour RTO says the service runs again within four hours. A fifteen minute RPO says you can lose the last fifteen minutes of writes and keep operating.
Teams often set one and assume the other follows. It does not. RTO drives how fast you can restart or switch over: standby capacity, failover automation, runbooks someone has actually executed. RPO drives how often you copy data and how writes are committed: backup cadence, log shipping, replication mode. A service with a one hour RTO and a nightly backup has a twenty four hour RPO, whether or not anyone wrote it down.
Set both per service. A payroll run and a marketing site do not need the same numbers, and one company wide target either overspends on the small system or leaves the important one short. Record each target in the service catalog, name an owner, and attach the test that proves it.
| Aspect | RTO | RPO |
|---|---|---|
| Unit of measure | Minutes or hours of downtime, from the start of the incident to verified recovery. | Minutes or hours of lost writes, counted backwards from the failure. |
| Clock direction | Forward: how long until the service is back. | Backward: how far the restore reaches into recent history. |
| Main design driver | Standby capacity, failover automation, DNS and dependency handling. | Replication mode, backup and log shipping frequency, durable write buffers. |
| Typical owner | Service owner with platform and infrastructure support. | Data owner with the database and application team. |
| Cheapest way to meet it | Degraded mode plus a manual runbook someone has run. | Shorter log shipping interval plus idempotent replay. |
| Failure mode when set too tight | Idle standby capacity that is never tested or trusted. | Synchronous writes that slow every transaction and couple replicas. |
| How to prove it | A failover drill using realistic traffic, timed from first failed request. | A restore into a scratch account with row counts and timestamps compared. |
How RTO works
An RTO needs a start line. Most teams measure from the moment someone declares an incident, which flatters the result: detection and the decision to fail over disappear from the clock. Measure from the first failed request or the first alert instead, and write that choice into the document. The end line matters too. Is the service recovered when a new instance passes a health check, or when a real customer completes a checkout? For anything customer facing, use the stricter definition.
Inside the clock sit detection, paging, the decision to act, the failover itself, DNS time to live, cache warm up, connection pools, secrets, token refresh and a check that data is current. Third parties count. If your login flow depends on an external identity provider, your RTO is partly their RTO, and their status page matters as much as your own architecture.
Define a degraded mode and give it a shorter RTO than full function. Serving a read only catalog in twenty minutes is often enough, with writes queued and replayed later. Publish both numbers: time to partial service and time to full service. Promising only the second one hides the work that keeps customers around.
How RPO works
RPO is measured in time, but the loss is data. It comes from backup frequency, transaction log shipping intervals, asynchronous replication lag, queue retention and batch exports. Each of those has a setting, and each setting behaves differently under load than its label suggests.
Configured lag is not observed lag. Asynchronous replicas fall behind during write bursts, network trouble and index rebuilds. Sample the lag during your busiest hour and during the largest write batch you expect, then treat the worst figure as your RPO. A target you only meet at quiet times is not a target.
Zero RPO requires synchronous commit on every write, and you pay in write latency and in the risk that a slow replica stalls the primary. That trade is sometimes right for a small ledger table and wrong for a product catalog.
Replication also copies mistakes. A dropped table or a bad migration lands on the replica within seconds, so an RPO does not cover you there. Pair it with point in time recovery and a runbook for restoring a single table without rolling back the entire database.
When to choose RTO
Lead with RTO when downtime hurts sooner than data loss. Storefronts, login, payment authorization, dispatch and customer support lines lose money by the minute. Losing the last few minutes of a session is annoying; an hour of a closed checkout is worse. In those services, the RTO justifies the standby capacity and the failover practice.
Stateless and read heavy services land here naturally. The data can be rebuilt, replayed or served from a cache, so the design effort goes into health checks that actually trip, traffic shifting, warm capacity in the second region and a load balancer weight change someone has rehearsed. Databases still constrain the number. A thirty minute RTO on an app whose primary database takes four hours to promote is fiction.
Take the RTO from the slowest dependency in the chain, then decide whether to shorten it or accept the larger number. Recording that dependency next to the target saves arguments later.
When to choose RPO
Lead with RPO when the lost writes are the expensive part. Ledgers, order intake, insurance claims, event streams and sensor ingestion all create work after the fact: reconciliation, duplicate charges, gaps that auditors ask about. The service can be down for an hour and everyone copes. The missing hour of transactions is the problem.
Design follows from that. Shorten log shipping. Use synchronous commit for the small set of tables that must not lose a row. Buffer writes durably at the edge so a failed consumer can replay them. Make handlers idempotent, keyed on a request id, so a replay does not create a second order.
An RPO led service still needs an RTO, or you get perfect data behind a door nobody can open. A common split is a stated but generous RTO with a tight RPO on the critical tables, and looser targets on derived data that can be rebuilt from the stream.
Costs and effort to consider
The standby you keep determines the bill. A hot standby runs the full stack in a second region and answers in minutes. A warm standby replicates data with the app switched off and starts in an hour or two. A cold standby is infrastructure as code plus a restore: cheap to hold, slow to use. Each step down saves monthly spend and adds hours, so the RTO has to be honest about which step you are paying for.
The other cost is people. Runbooks go stale. Drills need an owner, a window and a list of things to break: kill the primary, block the network path, expire a credential, restore a backup into a scratch account and compare row counts with the source. Schedule the drill after every architecture change and at a fixed interval for each tier one service. Tooling adds a line too, from replication bandwidth to snapshot storage and licensing that follows you into the standby.
Some teams write the targets and the architecture behind them in house. Others bring in a consultant for a short, fixed scope. Cloudverg's Discovery and roadmap sprint is $9,500/month, a two week engagement that ends with target architecture, a phased roadmap and a fixed price for phase one, with the fee credited to phase one if work starts within 60 days. It fits when the argument is about which service gets which target and what that costs to build.
Frequently asked questions
What is the difference between RTO and RPO?
RTO is how long a service can be down before it must be running again. RPO is how much data you can lose, expressed as time counted backwards from the failure. RTO drives failover speed and standby capacity, and RPO drives backup frequency and how writes are replicated.
Can an RPO be zero?
Strictly zero is possible only with synchronous writes on every transaction, which adds latency to each commit and can stall the primary when a replica slows down. Most teams set a small nonzero RPO for critical tables and accept that the last few seconds can be lost. Everything else runs on asynchronous replication with frequent logs.
How often should you test RTO and RPO?
Test each tier one service at least twice a year, after any change to its architecture, and whenever a critical dependency changes. Measure from the first failed request to verified customer function, and record how much data the restore actually lost. A drill nobody measures leaves you with a number on paper only.