RTO vs RPO: The Two Numbers That Decide How Bad an Outage Gets

Updated August 24, 2026

When your systems go down, two numbers decide how much the outage actually costs you: how long you stay down, and how much work you lose. Those two numbers are your RTO and your RPO.

Most business owners have never set them. Their IT provider may have picked them, or the backup software's default schedule set them by accident, without anyone asking what the business could actually afford. That's a problem, because you find out your real numbers during the outage, when it's already too late to change them.

This guide explains both in plain terms, shows how they quietly drive every dollar you spend on backups and recovery, and how to set them based on what your business can afford to lose.

The two numbers, in plain language

RTO is your Recovery Time Objective. It's how long your business can be down before the damage is unacceptable. Think of it as a target: when something fails, this is how fast you need to be running again.

RPO is your Recovery Point Objective. It's how much data or work you can afford to lose, measured in time. It answers a single question: when we recover, how far back in time do we restart from?

One is about time offline. The other is about work lost. They are independent of each other. You can recover fast and still lose a full day of data, or recover slowly with almost nothing lost. Which one matters more depends entirely on your business.

A concrete example

Picture a 15-person accounting firm. Their main server dies at 2 PM on a Tuesday.

The RPO side. Their last backup ran at midnight. Everything entered between midnight and 2 PM, fourteen hours of client work, is gone. That fourteen-hour gap is their real RPO, whether they chose it or not.

The RTO side. Rebuilding the server and restoring from backup takes their IT person nine hours. They're back online at 11 PM. That nine hours of downtime is their real RTO.

Now the business question: can this firm afford to re-enter fourteen hours of work and sit idle for nine hours? During tax season, absolutely not. In a quiet week in July, maybe. The point is that nobody decided this. The backup schedule and the restore process decided it for them, and they only learned the numbers when it was too late to lower them.

Why these two numbers drive everything you spend

Every dollar you spend on backups and recovery is really you buying these two numbers down. Lower numbers cost more, and the cost rises steeply as the numbers approach zero.

Want an RPO of five minutes instead of twenty-four hours? That means continuous replication of your data, not a nightly backup. More infrastructure, more cost.

Want an RTO of one hour instead of nine? That means a standby system ready to take over, not a from-scratch rebuild. More cost again.

This is exactly why RTO and RPO come first, before you buy anything. They tell you how much protection the business actually needs, so you don't overspend guarding against a problem you don't have, or underspend on the one that will sink you.

How to set your RTO

Don't start with technology. Start with money. For each critical system, ask what an hour of downtime costs you. If you don't have that number, the downtime cost calculator will give it to you in about two minutes.

Then ask where the downtime stops being an inconvenience and starts threatening the business. That threshold is your RTO. If an hour of downtime costs you $2,000 and the business can absorb roughly $8,000 of loss before it turns serious, your RTO is somewhere around four hours.

Set it per system, not once for everything. Your point-of-sale or your phones might need a one-hour RTO. An internal file server might be perfectly fine at twenty-four hours. Not everything deserves the same protection, and pretending it does is how you waste money on the systems that don't matter and starve the ones that do.

How to set your RPO

Here you ask a different question: if we lost every piece of work entered since the last backup, how much would it hurt, and how long would it take to recreate?

If your team enters high-value data all day, orders, transactions, client records, then a twenty-four-hour RPO means you could lose a full day of it. Recreating that work, if it can be recreated at all, is slow, expensive, and full of errors.

If your critical data barely changes from one day to the next, a twenty-four-hour RPO is fine. Match your backup frequency to how fast your important data actually changes, not to a default someone set once and never revisited.

The gap between what owners assume and what they actually have

Most owners assume that "we have backups" means they're covered. Backups set your RPO. They say nothing about your RTO. Having a backup does not mean you can restore it quickly, and it does not always mean you can restore it at all.

Two surprises show up again and again during real outages:

The backup is older than anyone thought. Nobody checked the schedule in months. The real RPO turns out to be days, not hours.

The restore takes far longer than expected, or fails outright. The real RTO turns out to be days too, because restoring a large system is slow and something in the chain was never tested.

If you have never restored from your backup and timed it, you do not know your real RTO. You have a hope, not a number. The businesses that survive outages are the ones that tested the restore before they needed it.

Common mistakes

One RTO and RPO for everything. Critical systems and nice-to-have systems end up with the same expensive protection, or the same inadequate protection. Neither is right. Rank your systems by what an outage of each one costs, and protect them accordingly.

Setting the numbers and never testing them. An untested recovery plan is a guess in a nice document. Your disaster recovery plan is only real once you've run it.

Confusing RTO with your provider's response time. The response time in your SLA is not your RTO. A provider can acknowledge your ticket in fifteen minutes and still take two days to get you running again.

Letting the backup software set your RPO by accident. The default schedule was chosen by a vendor who knows nothing about your business or what your data is worth. Choosing it yourself takes ten minutes and is the difference between losing an hour of work and losing a day.

The bottom line

RTO and RPO are business decisions wearing technical names. RTO is how long you can afford to be down. RPO is how much work you can afford to lose. Everything you spend on backups and recovery is you buying those two numbers down to a level the business can survive.

Set them per system, based on what an outage of each one actually costs you. Then test that your setup can genuinely hit them. Most businesses never do, which is why they discover their real numbers in the middle of an outage, when the numbers are already too high to fix.

Start with what downtime costs you: run the free downtime cost calculator. Then find every gap in your recovery setup, including the ones hiding in your backups, with the free Downtime Risk Self-Assessment.