RPO/RTO Gap Calculator

System or service:

Name the recovery target that owns these objectives.

Recovery tier:

Choose the tier label used in the DR runbook or business impact analysis.

Target RPO:

Enter the committed data-loss window for this service.

Measured RPO:

Use the worst credible recovered-data age, not the nominal backup interval.

Target RTO:

Enter the committed restore window for the service or process.

Measured RTO:

Include restore, validation, cutover, and handoff time that must finish before service is usable.

Check recovery inputs

{{ error }}

Change rate:

Leave 0 when transaction, record, or file-change rate is unknown.

changes/hr

Downtime exposure:

Leave 0 when cost modeling is not part of this review.

$ /hr

Objective tolerance: {{ formatPercent(target_buffer_percent, 0) }}

Use 0 for audit-grade strictness; any tolerance is shown in the gap matrix.

Evidence source:

This label appears in the exported evidence rows.

Evidence age:

Use 0 when the age is unknown or when this is a current test.

days

Check	Value	Evidence note	Copy
{{ row.check }}	{{ row.value }}	{{ row.note }}

Signal	Priority	Current state	Next action	Copy
{{ row.signal }}	{{ row.priority }}	{{ row.current }}	{{ row.action }}

Scenario	RPO position	RTO position	Result	Planning note	Copy
{{ row.scenario }}	{{ row.rpo }}	{{ row.rto }}	{{ row.result }}	{{ row.note }}

Enter valid RPO and RTO values to draw the objective gap chart.

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Disaster recovery planning becomes harder when the recovery promise is stated as a single phrase such as "restore quickly" or "keep backups current." Two separate clocks are involved. Recovery Point Objective (RPO) looks backward from an incident and asks how old the recovered data may be. Recovery Time Objective (RTO) looks forward from the incident and asks how long the service may be unusable.

The split matters because data loss and downtime often come from different weaknesses. A database might fail over in a few minutes while still replaying stale data. A backup might contain the right recovery point while the restore, validation, network cutover, and application handoff take hours. Treating RPO and RTO as one target hides the exact part of the recovery plan that needs work.

Timeline showing a recovery point before an incident and service restoration after the incident

RPO is usually influenced by backup frequency, replication lag, snapshot copy delay, transaction volume, and the ability to recover to a clean point before corruption. RTO is influenced by runbook clarity, restore speed, infrastructure readiness, access to people, dependency order, testing, and how long validation takes before users can rely on the service again.

Business impact should set the objective first. Technical capability then proves whether the objective is realistic. A payroll service, patient system, checkout flow, or control-plane dependency may justify tighter windows than a reporting archive. The same organization can also have different objectives for a regional failure, a database corruption event, or a seasonal peak when lost orders or delayed operations matter more.

Common RPO and RTO planning distinctions
Planning term	Question it answers	Common mistake
RPO	How old can the recovered data be?	Using the scheduled backup interval instead of the worst credible recovered-data age.
RTO	How long can the service be unavailable?	Stopping the clock at restore completion and leaving out validation, cutover, or handoff.
Recovery capability	What did the latest test or evidence show?	Assuming the architecture meets the objective without a recent recovery exercise.
Maximum tolerable downtime	How long can the business process survive disruption?	Setting an RTO that leaves no time for downstream cleanup or reprocessing.

A gap review is not a disaster recovery test by itself. It is a focused comparison between target windows and measured evidence. The result is useful when it points to a specific shortfall, names the evidence behind the measurement, and keeps data-loss risk separate from restore-time risk.

How to Use This Tool:

Enter one workload or service at a time so the result can be attached to the right recovery plan, evidence pack, or remediation ticket.

Set System or service to the workload name that appears in the recovery plan. If the name is longer than 120 characters, Check recovery inputs appears and the result rows switch to input issues.
Choose Recovery tier to keep the output aligned with the service catalog or business impact analysis. The tier label is informational and does not change the math.
Enter Target RPO and Target RTO with minutes, hours, or days. Use the approved objectives, not the latest test result.
Enter Measured RPO and Measured RTO from the newest defensible evidence. For RPO, use recovered-data age. For RTO, include restore, validation, cutover, and handoff time.
Open Advanced when the review needs Change rate, Downtime exposure, Objective tolerance, Evidence source, or Evidence age. Keep tolerance at 0 for strict checks unless the review policy permits a buffer.
Read Recovery Gap Matrix first. It shows RPO objective position, RTO objective position, Combined positive gap, optional exposure estimates, and the evidence note.
Use Remediation Runbook for action cues, Improvement Scenarios for rough planning comparisons, and Objective Gap Chart when a visual target-versus-measured comparison helps stakeholders see the miss.

If a duration, exposure value, or unit is rejected, fix the input before relying on any recovery claim. The blocked output is a signal that the evidence is not ready for review.

Interpreting Results:

Combined positive gap counts only missed-objective minutes. RPO headroom does not reduce an RTO miss, and RTO headroom does not reduce an RPO miss, because stale data and unavailable service create different business impacts.

Start with the two objective-position rows. A positive RPO objective position points toward backup cadence, replication lag, point-in-time recovery, or data consistency work. A positive RTO objective position points toward restore automation, capacity readiness, dependency order, validation steps, cutover, or a warmer recovery pattern.

RPO and RTO interpretation cues
Result cue	Boundary	What to do next
`objectives met`	RPO gap <= 0 and RTO gap <= 0	Keep the evidence with the runbook and retest after material changes.
`stale evidence`	No positive gaps and `Evidence age` > 90 days	Refresh the recovery exercise or attach newer monitoring evidence.
`RPO gap` or `RTO gap`	One signed gap is greater than 0 minutes	Work on the missed objective; do not average it with the passing one.
`dual gap`	Both signed gaps are greater than 0 minutes	Split remediation between data protection and restore-time work.
`severe` gap	Largest positive gap is at least 100% of its effective target	Escalate architecture, budget, or tier alignment before the next audit cycle.

A passing result can still be weak evidence. Check the Evidence source, Evidence age, and measured RTO definition before treating a pass as audit-ready. A restore time that excludes validation or a measured RPO based on a nominal schedule can make recovery look better than users would experience.

Technical Details:

Recovery-objective gap analysis is a signed duration comparison. Target and measured values must share a common unit before comparison, so minutes, hours, and days are first converted to minutes. A measured value below the effective target produces headroom. A measured value above the effective target produces a positive gap.

Objective tolerance expands the target before the comparison. A 10% tolerance changes a 60-minute target into a 66-minute effective target. This can be useful when a governance process explicitly allows a review buffer, but it should stay at 0 for strict RPO/RTO evidence checks.

Formula Core:

The same signed-gap rule is applied separately to RPO and RTO, then the positive portions are added.

\begin{array}{rcl} E_{RPO} & = & T_{RPO} \times (1 + b / 100) \\ E_{RTO} & = & T_{RTO} \times (1 + b / 100) \\ G_{RPO} & = & M_{RPO} - E_{RPO} \\ G_{RTO} & = & M_{RTO} - E_{RTO} \\ P & = & \max (0, G_{RPO}) + \max (0, G_{RTO}) \end{array}

T is the target duration in minutes, M is the measured duration in minutes, E is the effective target after tolerance, G is the signed gap, b is objective tolerance percent, and P is the combined positive gap.

With target RPO 15 minutes, measured RPO 45 minutes, target RTO 60 minutes, measured RTO 90 minutes, and tolerance 0%, the RPO gap is 30 minutes and the RTO gap is 30 minutes. Combined positive gap is 60 minutes because both objectives miss.

Recovery objective formulas and boundaries
Mechanism	Rule or boundary	Interpretation
Duration units	minutes, hours, days	All durations are converted to minutes before gap calculation.
Objective tolerance	0% to 50%	The tolerance percent expands both target windows before misses are flagged.
RPO change exposure	`max(0, RPO gap) / 60 x change rate`	Estimated extra changes at risk beyond the data-loss objective.
RTO cost exposure	`max(0, RTO gap) / 60 x downtime exposure`	Estimated extra impact beyond the restore-time objective.
Stale-evidence cue	Evidence age > 90 days and both gaps <= 0	A pass remains flagged when the supporting recovery evidence is old.
Severe cue	Largest positive gap / effective target >= 1	The measured miss is at least as large as the allowed objective window.

Improvement scenarios are deterministic what-if rows, not platform forecasts. The current measured state uses the entered values. Backup cadence and replication tuning model RPO at 50% of measured and RTO at 95% of measured. Restore automation models RPO at 90% and RTO at 65%. A warmer recovery pattern models RPO at 35% and RTO at 45%. The objective boundary row shows the exact effective targets.

Comparisons are meaningful only when the measurement scope stays consistent. Use the same incident start point, the same definition of "service usable," the same evidence standard, and the same inclusion of validation and handoff time when comparing two runs.

Accuracy Notes:

RPO/RTO gaps are only as strong as the evidence behind the measured values. The arithmetic is exact for the values entered, but the result cannot prove that people, dependencies, credentials, capacity, or a recovery site will behave the same way during a real incident.

Use test evidence, incident reviews, backup restore reports, or replication checks that match the workload being reviewed.
Record stale evidence instead of silently treating old tests as current recovery capability.
Do not treat the optional change-rate and downtime-cost estimates as accounting figures unless those rates come from an approved business-impact model.
Review dependent workloads when their RPO or RTO would prevent this service from meeting its own objective.

Advanced Tips:

Keep Objective tolerance at 0 for audit-style reviews. Use a tolerance only when the recovery policy explicitly allows a buffer, because it expands both target windows before misses are flagged.
Enter Measured RPO as recovered-data age, not the backup schedule. Replication delay, snapshot copy time, and point-in-time recovery limits can make the recovered point older than the nominal interval.
Enter Measured RTO through the moment the service is usable. Restore completion alone can understate the gap when validation, cutover, DNS, dependency checks, or handoff still remain.
Use Change rate and Downtime exposure only when those rates come from the same business-impact model used to set the tier. Otherwise leave them at 0 and treat the gap minutes as the safer evidence.
Compare Improvement Scenarios as planning sketches, not vendor promises. The rows apply fixed reduction factors to the measured state so teams can discuss which recovery work might close the largest gap first.
Use Objective Gap Chart for stakeholder review when the difference between target and measured values needs to be visible at a glance, then keep the matrix rows as the evidence record.

Worked Examples:

Dual miss in a Tier 1 database

A Tier 1 billing database has target RPO 15 minutes, measured RPO 45 minutes, target RTO 60 minutes, and measured RTO 90 minutes. RPO objective position shows 30 minutes gap, RTO objective position shows 30 minutes gap, and Combined positive gap shows 1 hour. The remediation work should cover both data protection and restore-time steps.

RTO miss with RPO headroom

A reporting service has target RPO 4 hours and measured RPO 3 hours, so the data-loss objective has 1 hour of headroom. If target RTO is 6 hours and measured RTO is 7 hours, RTO objective position still shows 1 hour gap. The passing RPO does not cancel the restore-time miss.

Severe restore-time gap

A customer portal has target RTO 30 minutes and measured RTO 75 minutes with a 0% tolerance. The positive RTO gap is 45 minutes, which is at least 100% of the 30-minute effective target, so the summary badge moves to a severe RTO gap. A small runbook tweak may not be enough; the architecture or recovery tier likely needs review.

Stale passing evidence

A service with no positive gaps and Evidence age set to 120 days returns a stale-evidence cue. The fix is not changing the target. Attach fresher evidence, run another recovery exercise, or mark the pass as unsupported until the evidence is current.

FAQ:

Should measured RTO include validation time?

Yes. Use the time until the service is usable, including restore, validation, cutover, and handoff. Leaving validation out makes the RTO gap look smaller than the recovery users experience.

Can RPO headroom offset an RTO gap?

No. Combined positive gap adds only missed-objective minutes. A service can protect data well and still be down too long, or recover quickly while losing too much recent data.

When should I use objective tolerance?

Use Objective tolerance only when the review policy allows a measured value to exceed the stated target by a set percent. Keep it at 0 for strict evidence checks.

Why does stale evidence appear when objectives pass?

When both gaps are nonpositive and Evidence age is greater than 90 days, the result flags stale evidence. It means the numbers pass, but the supporting test or report should be refreshed.

Why are the result rows replaced by input issues?

Negative duration or exposure values, unsupported duration units, or a service name over 120 characters trigger Check recovery inputs. Correct those values before using the gap matrix.

Glossary:

RPO: Recovery Point Objective, the maximum acceptable age of recovered data after an incident.
RTO: Recovery Time Objective, the maximum acceptable time until the service is usable again.
Effective target: The target duration after any objective tolerance has been applied.
Signed gap: The measured value minus the effective target, where positive means a miss and negative means headroom.
Combined positive gap: The sum of positive RPO and RTO gaps, with headroom ignored.
Evidence age: The age in days of the test, dashboard, incident review, or backup report supporting the measured values.
Recovery capability: The recovery performance shown by tests or operational evidence, as distinct from the target objective.

References:

Contingency Planning Guide for Federal Information Systems, NIST, May 2010, updated November 11, 2010.
REL13-BP01 Define recovery objectives for downtime and data loss, AWS Well-Architected Framework.
REL13-BP02 Use defined recovery strategies to meet the recovery objectives, AWS Well-Architected Framework.
Business continuity, high availability, and disaster recovery, Microsoft Learn.
Disaster recovery planning guide, Google Cloud Architecture Center, last reviewed July 5, 2024.