What are RPO and RTO, and what should a 10-person SaaS aim for?

What is RPO in plain English?

RPO is how far back in time you are willing to go when you recover.

An RPO of one hour means that, in the worst case, you accept losing the last hour of data. It is decided by how often your data is backed up or replicated, not by how quickly you restore.

What is RTO in plain English?

RTO is how long your product can be unavailable before the damage is unacceptable.

An RTO of four hours means you aim to be working again within four hours of deciding to recover. It is decided by how fast you can restore, reconfigure and verify, which you only know by testing.

What RPO and RTO should a small SaaS aim for?

A small SaaS can usually aim for an RPO of minutes and an RTO of a few hours for its main database, with looser targets for files, caches and analytics.

There is no single right answer, but these are reasonable starting points for a SaaS team of around ten people. Agree them with whoever owns customer contracts, because some enterprise customers will ask.

Amazon RDS point-in-time restore can usually restore to within about the last five minutes, which makes an RPO of minutes realistic for the main database. RTO is harder, because it includes people and process as well as the restore itself.

Does Multi-AZ mean you do not need backups?

No. Multi-AZ keeps a standby copy of your database in another availability zone, which protects you against an instance or zone failure.

But it replicates every change, including accidental deletes, bad migrations and corruption. Only backups let you go back to a point before the mistake. You need both for different reasons.

How do you know if you can meet your RTO?

You know by timing a real restore from start to a working application, not just the database restore.

Add up the steps:

1. Noticing the problem and deciding to restore.
2. Running the restore itself.
3. Pointing the application and secrets at the restored database.
4. Checking the data and running a smoke test.
5. Telling customers you are back.

If the total is longer than your RTO, either speed up the slow steps, for example with a written runbook and pre-built restore scripts, or agree a longer RTO honestly. The RDS restore guide shows how to time the restore step.

How do RPO and RTO apply to a full AWS region outage?

Covering a full region outage means copying backups to a second region and being able to rebuild from infrastructure as code, usually with a longer RTO than for everyday incidents.

A full region outage is rare but possible. Covering it means copying backups to a second region and being able to rebuild your infrastructure there, which is much easier if everything is defined as code. For many small SaaS teams, a sensible middle ground is cross-region backup copies plus infrastructure as code, with a longer RTO for that scenario than for everyday incidents.

Do you know your real RPO and RTO?

Tick each statement you can confirm with evidence.

Who decides the RPO and RTO for a SaaS product?

The business decides, and engineering checks whether it is achievable.

A founder or CTO should set the targets based on what customers and contracts expect, then confirm with a timed restore that the setup can meet them. If the answer is no, either invest in the setup or agree a looser target honestly. Promising an RTO you have never tested is the most common mistake.

What should you tell customers about RPO and RTO?

Tell customers only what you have tested.

A clear, modest statement, such as backups every few minutes with point-in-time restore, restore tested monthly, and a target recovery time of a few hours, is more convincing to an enterprise security reviewer than an ambitious number with no evidence. Keep your latest restore test report ready to share on request.

How do RPO and RTO change as a SaaS grows?

Targets usually tighten as revenue and customer expectations grow.

Early on, a few hours of downtime might be acceptable. Later, contracts may require tighter targets, which can mean Multi-AZ databases, cross-region backup copies, warm standby environments and more frequent drills. Review your targets once a year, or when you sign a customer with specific recovery terms.