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.

Export to PDF Fullscreen

Embed:

Customize

Include current inputs

Size

Advanced

Width

Height

Aspect ratio

Max height

Collapsible embed

Allow fullscreen

Referrer policy

Sandbox tokens

Recovery Point Objective, or RPO, is the maximum acceptable age of recovered data after an outage. Recovery Time Objective, or RTO, is the maximum acceptable time for a service to return to a usable state. Together they turn a disaster recovery promise into two measurable limits: how much data can be lost and how long the service can be down.

These objectives matter because a restore can look successful while still failing the business need. A database may come back after a clean restore, but if the latest usable recovery point is 45 minutes old against a 15-minute RPO, too much data is at risk. A service may recover with all data intact, but if validation, cutover, and handoff take 90 minutes against a 60-minute RTO, the downtime objective is still missed.

Timeline showing RPO as data age before an incident and RTO as downtime after the incident

RPO and RTO should come from the service tier, business impact analysis, recovery plan, or service commitment, not from whatever the backup platform happens to provide. The measured values should come from recovery tests, replication lag, backup reports, incident records, or other evidence that reflects the worst credible recovery path.

A gap calculation is not a certification that recovery will work during an incident. It is a planning check that shows whether measured capability fits the stated objectives, where the shortfall sits, and which evidence needs a fresh review before the result is trusted.

Technical Details:

RPO compares a recovery point against an allowed data-loss window. If the latest usable point is older than the target, the excess age is a data-loss gap. RTO compares elapsed recovery time against an allowed downtime window. The elapsed time should include restore work, validation, cutover, and handoff because the service is not recovered until it is usable.

The calculation treats RPO and RTO as separate objectives. Headroom on one objective does not cancel a miss on the other because data loss and downtime have different business consequences. A service can meet the restore-time target while losing too much data, or protect the data while taking too long to return.

Formula Core:

Each entered duration is converted to minutes. Objective tolerance expands both targets by the same percentage before the measured values are compared.

\begin{matrix} 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_{total} & = & \max (0, G_{RPO}) + \max (0, G_{RTO}) \end{matrix}

A positive gap means the measured value is outside the allowed objective. A negative gap is headroom. Values that round to zero are treated as on target for display, while the comparison still follows the converted minute values.

RPO and RTO formula symbols
Symbol	Meaning	Unit
`T_RPO`, `T_RTO`	Target RPO and target RTO before tolerance.	minutes
`M_RPO`, `M_RTO`	Measured RPO and measured RTO from backup, replication, incident, or recovery-test evidence.	minutes
`b`	Objective tolerance applied to both targets. A value of 0 keeps a strict comparison.	percent
`G_RPO`, `G_RTO`	Signed objective position. Positive values are gaps; negative values are headroom.	minutes
`P_total`	Combined positive gap. Only missed-objective minutes are counted.	minutes

Optional exposure estimates attach business context to positive gaps. Data-loss exposure multiplies extra RPO minutes by the entered change rate. Downtime exposure multiplies extra RTO minutes by the entered cost or impact rate. When either rate is left at 0, that exposure is reported as not modeled.

\begin{matrix} X_{changes} & = & \max (0, G_{RPO}) / 60 \times R_{change} \\ X_{downtime} & = & \max (0, G_{RTO}) / 60 \times R_{cost} \end{matrix}

Result state is based on positive gaps first, then evidence age. A gap is marked severe when the largest positive gap is at least as large as its effective target. Evidence becomes stale after 90 days only when both objectives are otherwise inside target.

Recovery objective result states and boundaries
State cue	Boundary	Meaning
`objectives met`	RPO gap <= 0 and RTO gap <= 0, with evidence age at 90 days or less.	Measured recovery is inside both targets.
`stale evidence`	No positive gaps, evidence age > 90 days.	The numbers pass, but supporting evidence should be refreshed.
`RPO gap` or `RTO gap`	One objective has a positive gap smaller than its effective target.	One recovery objective is missed.
`severe RPO gap` or `severe RTO gap`	One positive gap is at least 100% of its effective target.	The measured value is at least twice the allowed window for that objective.
`dual gap`	Both objectives have positive gaps, and the largest gap ratio is below 100%.	Data age and downtime both exceed their targets.
`dual severe gap`	Both objectives miss, and at least one positive gap is 100% or more of its effective target.	Both objectives need remediation, with at least one large miss.

Accepted duration units are minutes, hours, and days. Durations, change rate, and downtime exposure must be nonnegative. The service name must stay under 120 characters so copied rows and exported evidence remain readable.

Everyday Use & Decision Guide:

Use one service, workload, database, or recovery plan at a time. The service tier label keeps the result aligned with the business impact analysis or runbook, but it does not change the math. A Tier 1 workload and a Tier 4 workload with the same targets and measurements produce the same gap values.

Use target values from the approved recovery objective, then use measured values from the most credible evidence available. For measured RPO, choose the worst recovered-data age you would defend in a review, such as replication lag during a failover test or the age of the latest usable backup. For measured RTO, include restore, validation, cutover, and handoff time until the service is usable.

Keep Objective tolerance at 0 for strict audit checks.
Use a small tolerance only when the review policy explicitly allows a buffer above the target.
Set Change rate when extra RPO minutes should be translated into approximate changes at risk.
Set Downtime exposure when extra RTO minutes should be valued as cost or impact.
Record Evidence source and Evidence age when the result will be copied into a remediation review.

The summary tells you which objective is missed and how much positive gap remains. The Recovery Gap Matrix is the best place to check exact target, measured, tolerance, exposure, and evidence rows. The Remediation Runbook turns the same result into priority cues, while Improvement Scenarios shows how backup tuning, restore automation, or a warmer recovery pattern would change the measured position.

The Objective Gap Chart is useful for explaining the miss to stakeholders because it places effective target and measured minutes next to each other for RPO and RTO. If the chart shows only one bar above target, focus the next review on that objective. If both measured bars exceed target, split the action plan between data protection and restore-time work.

Step-by-Step Guide:

Build the check from the recovery objective first, then compare measured evidence against it.

Enter System or service. If the name is too long, Check recovery inputs will report that it must stay under 120 characters.
Choose Recovery tier. The summary badge should show the selected tier, such as Tier 1, without changing any duration math.
Enter Target RPO and Target RTO with the correct units. These become the strict objectives before tolerance.
Enter Measured RPO and Measured RTO. The summary should show either No gap or the combined positive gap in minutes, hours, or days.
Open Advanced when the review needs Change rate, Downtime exposure, Objective tolerance, Evidence source, or Evidence age. The matrix should then show tolerance, exposure, and evidence rows.
If Check recovery inputs appears, fix negative duration or exposure values before using the result. The matrix rows will repeat the input issue until the values are valid.
Review Recovery Gap Matrix for exact values, then use Remediation Runbook to identify whether data-loss work, restore-time work, tier review, exposure modeling, or evidence refresh is the next action.
Open Objective Gap Chart when you need a visual comparison of effective target minutes and measured minutes. Use JSON when the same result needs a structured handoff.

Interpreting Results:

The summary value is the combined positive gap. It counts only the minutes that exceed target, so spare RPO headroom does not reduce an RTO miss and spare RTO headroom does not reduce an RPO miss. Read the badges beside the summary before deciding which team owns the next action.

How to interpret RPO and RTO calculator outputs
Output cue	Read it as	Check next
`RPO ... gap`	Recovered data would be older than the objective allows.	Review backup cadence, replication lag, snapshot copy time, and application-consistency delay.
`RTO ... gap`	The service would return later than the objective allows.	Review restore steps, validation time, cutover work, and warm-standby options.
`Combined positive gap`	Total missed-objective minutes across RPO and RTO.	Use this for scale, then split remediation by objective.
`RPO gap change exposure`	Estimated extra changes at risk from RPO minutes beyond target.	Confirm the entered change rate reflects the workload period being reviewed.
`RTO gap cost exposure`	Estimated extra cost or impact from RTO minutes beyond target.	Confirm the cost rate is approved for the service or business process.
`stale evidence`	Objectives pass, but the evidence age is greater than 90 days.	Schedule a new recovery test or attach fresher monitoring evidence.

Do not treat objectives met as proof that recovery is ready. The calculation does not test backup integrity, credentials, target capacity, application consistency, operator access, or disaster-time contention. Use the result to focus the review, then keep recovery-test evidence with the runbook.

A severe result is a prioritization signal, not a root-cause diagnosis. Use the Remediation Runbook row for the missed objective, then verify the underlying evidence before committing to a technology change or a revised service tier.

Worked Examples:

Critical database with both objectives missed. A Tier 1 billing database has a target RPO of 15 minutes and a measured RPO of 45 minutes. Its target RTO is 60 minutes and measured RTO is 90 minutes. With Objective tolerance at 0, the Recovery Gap Matrix reports a 30-minute RPO gap, a 30-minute RTO gap, and a 60-minute Combined positive gap. Because the RPO gap is at least as large as the 15-minute target, the summary shows dual severe gap.

If that same database changes at 600 records per hour and downtime exposure is entered as $12,000 per hour, the RPO exposure is about 300 changes and the RTO exposure is about $6,000. Those values do not prove business loss, but they give the remediation review a scale for backup cadence, replication, restore automation, and standby design.

Borderline pass with stale evidence. A payroll service has a 2-hour target RPO and a 4-hour target RTO. Measured RPO is 2.1 hours, measured RTO is 3.5 hours, and Objective tolerance is set to 10%. The effective targets become 2.2 hours for RPO and 4.4 hours for RTO, so both objective positions show headroom. If Evidence age is 120 days, the summary still warns stale evidence because the pass depends on old support.

Input issue before the review starts. A user enters -5 minutes for Measured RPO after copying a spreadsheet value with the wrong sign. The summary changes to Recovery inputs need review, and the matrix reports Measured RPO cannot be negative. Fixing the value restores the objective rows, chart, and JSON payload.

FAQ:

What is the difference between RPO and RTO?

RPO is about recovered data age, so it compares Target RPO with Measured RPO. RTO is about downtime, so it compares Target RTO with Measured RTO.

Why does headroom on one objective not cancel a gap on the other?

The calculator counts only positive RPO and RTO gaps in Combined positive gap. Extra restore-time headroom does not reduce data-loss risk, and extra data-protection headroom does not shorten downtime.

When should objective tolerance be above 0?

Use Objective tolerance above 0 only when the review policy allows a buffer above the strict target. The tolerance is shown in the matrix and is applied to both RPO and RTO before a miss is flagged.

Why do I see Check recovery inputs?

That state appears when a value fails validation, such as a negative RPO, RTO, change rate, or downtime exposure, or a service name over 120 characters. Fix the listed issue before relying on the result.

Does the calculator send recovery values to a server?

The calculations, tables, JSON, and chart data are produced in the browser. Recovery values are not submitted to a separate calculation service by this calculator.

Glossary:

Recovery Point Objective (RPO): Maximum acceptable age of recovered data after an outage.
Recovery Time Objective (RTO): Maximum acceptable elapsed time before the service is usable again.
Measured RPO: Worst credible recovered-data age from backup, replication, or recovery-test evidence.
Measured RTO: Observed or estimated restore time through validation, cutover, and handoff.
Objective tolerance: Optional percentage buffer added to both targets before the gap comparison.
Evidence age: Number of days since the recovery evidence was produced or reviewed.
Headroom: Minutes by which the measured value is inside the effective target.
Positive gap: Minutes by which the measured value exceeds the effective target.

References:

Contingency Planning Guide for Federal Information Systems, National Institute of Standards and Technology, May 2010.
IT Disaster Recovery Plan, Ready.gov, February 5, 2025.
Disaster Recovery (DR) objectives, AWS Well-Architected Framework.