The Clock is Ticking: Calculating the True Cost of Downtime (RTO vs. RPO)
Why "Good Enough" Recovery Objectives Could Cost Your Business Millions, and How to Get the Budget You Need for Real Resilience.
If you read my last post, you’ll know that one of the biggest roadblocks to properly testing our Disaster Recovery (DR) plans is always the same: budget (Roadblock #3, if you’re counting).
When we ask the finance director or the CEO for funds to run a full, disruptive DR test, the question we often hear back is, “Why should we spend money proving something works when the backups are already running?”
The answer isn’t technical; it’s financial. We need to stop talking about servers and start talking about risk, recovery, and money. The language we must master to win that argument is the language of the two metrics that define our survival: RTO and RPO.
🧭 The Two Metrics That Define Survival
These concepts are more than just acronyms; they are the financial pillars of our business continuity planning. They represent the maximum loss that our business can tolerate before the crisis becomes catastrophic.
1. RPO: Recovery Point Objective (The Data Loss Metric)
The RPO defines the maximum amount of data (measured in time) that a business can afford to lose following a disaster.
Simply put: If your RPO is 1 hour, your backup system must ensure you can recover all data up to 60 minutes before the failure. Losing more than 60 minutes of data is unacceptable.
The Financial Consequence: An RPO failure means lost transactions, compliance breaches (think GDPR or FCA fines), and massive staff labour costs for manual data reconstruction. The tighter your RPO, the more expensive your technology is, requiring solutions like continuous replication.
2. RTO: Recovery Time Objective (The Time Loss Metric)
The RTO defines the maximum amount of time (measured in hours or minutes) that a business can afford to be down before services are restored and running again.
Simply put: If your RTO is 4 hours, your entire recovery process—from the point of data loss to systems fully operational—must be complete within that time frame.
The Financial Consequence: An RTO failure means direct revenue loss, contractual penalties (Service Level Agreements), and rapid customer churn. The tighter your RTO, the more critical the need for automated, tested failover procedures.
💷 Justifying the Investment: The Cost of Downtime
To get the budget we need for rigorous testing, we have to quantify the risk of missing our RTO. We need to present management with the raw, brutal maths of what one hour of downtime truly costs.
Here is a simplified calculation that I use when talking to non-technical executives:
Total Cost of Downtime per Hour = Lost Revenue + Lost Productivity + Recovery Costs + Intangible Costs
Lost Revenue Calculation
We can start with a basic revenue loss calculation:
Calculate Revenue per Hour: Take your Annual Revenue and divide it by the number of working hours per year (e.g., 2080 hours for 40 hours a week).
Example: If your business turns over £5 million annually, your lost revenue is approximately £2,400 per hour of downtime.
Lost Productivity
This covers the hourly wages of every employee who is sitting idle because your critical systems are unavailable. If 100 staff earning an average of £30 per hour are affected, that’s another £3,000 per hour, straight out of the operating budget.
The Trade-Off: RTO vs. Testing Costs
The real breakthrough comes when we compare the cost of downtime to the cost of improvement.
If our current, untested plan has a realistic RTO of 8 hours, and our downtime cost is £5,400 per hour, we are exposing the business to a £43,200 loss.
If we can invest £10,000 in a dedicated test environment and two weeks of staff time to prove we can hit a 4-hour RTO, we have effectively bought an insurance policy that saves the business over £20,000 every single time a major incident occurs.
This is the conversation management understands. We aren’t asking for money for a shiny new server; we are asking for money to reduce risk by a specific, measurable amount.
⚖️ The Compliance and Reputational Hammer (RPO Justification)
The RPO conversation is often harder but carries a bigger stick: regulatory fines and reputation damage.
Regulatory Risk
For heavily regulated sectors (Finance, Insurance, or anyone dealing with EU data), an RPO failure that results in losing records or failing to report transactions immediately triggers massive fines that dwarf any lost revenue.
Intangible Costs
When an outage happens, the intangible costs mount quickly:
Customer Churn: How many clients will leave after an extended outage?
Brand Damage: The cost of rebuilding trust after your company is trending on X (Twitter) for being down.
Staff Morale: The cost of burnout and stress on the team desperately trying to recover an untested system.
This is why we must apply the tightest RPO (e.g., minutes, seconds) only to the most mission-critical applications—the databases or transactional systems—as anything stricter than an hour costs serious money. We use the cost of compliance failure to justify that expense.
🚀 Final Thought: Use Data, Not Fear
The next time a business leader asks why your DR plan needs more budget, don’t talk about the complexity of the storage arrays or the difficulty of the script. Talk about RTO and RPO.
Use the calculated cost of downtime to show that DR testing is not an expense; it is a cheap insurance policy against catastrophic financial risk. We move from saying “we hope it works” to confidently saying, “We have tested and verified that we can save the business £20,000 an hour.”
A Note on Production: The core analysis, original ideas, and expert opinions contained within this post are entirely my own. I utilised a large language model (AI) to refine the structure and polish the phrasing to ensure maximum clarity and readability for you - the reader.
I am a Salesforce employee; these views are my own and do not represent Salesforce.
So, I’m curious: Do you already have a quantified cost of downtime for your organisation? If not, what’s stopping you from running the numbers? Share your thoughts below!