How to Calculate Your RTO and RPO — With Real Numbers

RTO and RPO are the two numbers your entire disaster recovery plan depends on. Get them wrong and you'll either overspend on infrastructure you don't need or under-protect systems that generate revenue. This article walks through the formulas, shows worked examples, and gives you a worksheet to calculate both for your own environment.

No theory. Just math.

What RTO and RPO Measure

Quick definitions.

RTO (Recovery Time Objective) = the maximum acceptable time between a disruption and full service restoration. Measured in hours or minutes. Example: an RTO of 4 hours means the system must be operational within 4 hours of failure.

RPO (Recovery Point Objective) = the maximum acceptable amount of data loss measured in time. Example: an RPO of 1 hour means you can lose, at most, 1 hour of data. Your backup or replication frequency must match or exceed this.

These are business metrics, not technical ones. They're set by the business based on financial impact, not by IT based on what's convenient.

Step 1: Calculate Downtime Cost

You need a dollar figure per hour of downtime. Here's the formula:

Hourly downtime cost = (Annual revenue from system / 8,760) + hourly labor cost of idle workers + estimated hourly penalty/SLA exposure

Worked example. Your e-commerce platform generates $4.1 million per year in revenue. You have 12 staff members who can't work during an outage, averaging $45/hour. Your SLA with your largest client includes a $5,000 penalty per hour of unplanned downtime after the first 2 hours.

• Revenue per hour: $4,100,000 / 8,760 = $468/hour
• Idle labor: 12 × $45 = $540/hour
• SLA penalty (after hour 2): $5,000/hour

Total cost in hour 1: $1,008. Total cost in hour 3: $6,008. It escalates fast.

Step 2: Set Your RTO

The formula:

RTO = Maximum tolerable downtime × 0.75

Why 0.75? Because recovery rarely goes exactly to plan. You want a buffer. If the business says 8 hours is the absolute limit, target 6 hours. If 4 hours is the limit, target 3.

From our example: if leadership says $25,000 in total losses is the threshold — that's roughly hour 5 (accounting for the escalating SLA penalties). Apply the 0.75 factor: RTO = 3.75 hours, round down to 3.5 hours.

Step 3: Set Your RPO

For RPO, you need the data change rate and the value of that data:

RPO = Maximum tolerable data loss (in $) / hourly data value

If your order system processes $468/hour in transactions and the business can absorb losing up to $2,000 in transaction data before reconciliation becomes a nightmare:

RPO = $2,000 / $468 = 4.27 hours

Round down. RPO = 4 hours. That means backups every 4 hours minimum — or better, continuous replication if you want a margin of safety.

The Calculation Worksheet

Use this table for each system in your environment.

Field	Your Value	Example
System name	—	Order Management Platform
Annual revenue attributed	—	$4,100,000
Revenue per hour (A / 8,760)	—	$468
Idle staff count	—	12
Average hourly labor cost	—	$45
Hourly labor impact	—	$540
SLA/penalty per hour	—	$5,000 (after hour 2)
Maximum tolerable downtime	—	5 hours
RTO (tolerable × 0.75)	—	3.5 hours
Hourly data value	—	$468
Maximum tolerable data loss ($)	—	$2,000
RPO (loss $ / hourly value)	—	4 hours

Fill one row per system. Start with Tier 1 — revenue-generating applications, customer-facing services, anything with regulatory obligations. You can estimate for Tier 3 and 4 systems.

Common Mistakes in RTO/RPO Calculation

Three things to watch for:

1. Confusing RTO with actual recovery time. RTO is the target. Actual recovery time is what happens during a real incident. If your RTO is 4 hours but your last test took 6.5 hours, you have a gap. Not a plan.
2. Setting RPO based on backup schedule instead of the other way around. The backup schedule should follow the RPO. "We back up daily" is a statement about your infrastructure. "Our RPO is 24 hours" is a business decision. The first should follow from the second.
3. Ignoring cascading dependencies. System A might have a 2-hour RTO, but if it depends on System B which has a 6-hour RTO, System A's real RTO is 6 hours. Map dependencies before setting targets.

When This Approach Doesn't Apply

Dollar-based calculations work well for revenue-generating systems. They're less useful for internal tools, collaboration platforms, or systems where the impact is productivity rather than direct revenue. For those, use a qualitative scale: critical, high, medium, low — and assign RTOs by tier rather than by formula.

Also: if your organization has fewer than 50 employees and runs fewer than 10 production systems, a full per-system calculation might be overkill. Set two or three RTO/RPO tiers and slot each system in. Save the detailed math for the systems that generate money.