How to Estimate Downtime Without Inventing an Industry Average
“How much does one hour of downtime cost?”
It sounds like a question that should have one neat answer.
It does not.
A payment platform, school management system, internal file server, factory production system and hotel reservation platform can all fail for one hour and create completely different business consequences.
Even two companies using the same technology can experience different losses depending on:
- Number of people affected
- Time of day
- Transaction volume
- Available workarounds
- Customer commitments
- Recovery capability
That is why a company-specific estimate is usually more useful than borrowing an impressive industry average.
The objective is not to create the largest possible number.
It is to create a transparent estimate leadership can use when deciding what deserves stronger recovery.
Start With the Service That Failed
Before calculating anything, define the disruption.
What became unavailable?
It might be:
- Internet connectivity
- Payment processing
- ERP
- CRM
- Customer portal
- Cloud application
- Production system
- One business location
Then distinguish between:
Complete outage
The service cannot be used.
Degraded service
The service continues but with limited capacity or reliability.
Channel outage
One route is unavailable, but an alternative remains.
That distinction affects every assumption that follows.
1. Estimate Staff Impact
Start with the people whose work is affected.
A simple formula is:
Affected people × Loaded hourly cost × Percentage of useful work lost × Outage duration
The important phrase here is useful work lost.
Do not automatically assume everyone becomes 100% unproductive.
Some employees may be able to:
- Switch tasks
- Work offline
- Use another system
- Handle calls
- Complete administrative work
Others may be completely blocked.
The percentage should reflect the operating reality.
What Is Loaded Hourly Cost?
Loaded cost is broader than salary alone.
Depending on the organisation’s methodology, it may include relevant employment costs associated with the employee.
Finance or HR should approve the assumption.
The objective is consistency, not artificial precision.
2. Separate Delayed Transactions From Permanently Lost Contribution
This distinction can change the calculation significantly.
Suppose an outage interrupts 100 transactions.
It does not automatically mean all 100 are lost.
Some customers may return once the service is restored.
Others may use another channel.
A smaller proportion may disappear completely.
So estimate:
- Expected transactions during the affected period
- Average contribution per transaction
- Percentage likely to be permanently lost
The formula is:
Expected transactions × Contribution per transaction × Permanent-loss percentage
Notice that this uses contribution, not automatically total transaction value.
If a ₦100,000 sale requires substantial direct cost to fulfil, treating all ₦100,000 as economic loss may exaggerate the impact.
Finance should determine the appropriate contribution measure.
Delayed Is Not Lost
Keep these categories separate:
- Transactions delayed
- Transactions permanently lost
- Sales value delayed
- Contribution permanently lost
- Cash collection delayed
A delay can create operational problems without becoming permanent revenue loss.
That is worth recording.
It is simply a different kind of impact.
3. Add Direct Recovery Costs
Downtime can create expenses beyond lost productivity and transactions.
These may include:
- Emergency vendor support
- Overtime
- Temporary connectivity
- Temporary equipment
- Additional transport
- Restoration activity
- Data reconciliation
- Backlog processing
- Customer communication
Use documented costs where possible.
Where estimates are necessary, record the assumptions.
The same applies to contractual consequences such as:
- Service credits
- Penalties
- Compensation
Use actual contractual terms rather than theoretical amounts.
4. Record Non-Financial Impact Separately
Not every consequence needs a naira value.
Customer trust and reputation matter.
But attempting to assign a precise monetary value without an approved methodology can make the model look more certain than it really is.
Instead, record evidence such as:
- Customers affected
- Missed commitments
- Complaints
- Escalations
- Delayed deliveries
- Required notifications
- Service failures
- Operational control issues
This gives leadership visibility without inventing a financial figure.
An Illustrative Downtime Scenario
The example below is hypothetical.
Get Techbotsltd’s stories in your inbox
Join Medium for free to get updates from this writer.
It is not a TechBots client result, Nigerian industry benchmark or prediction.
Every assumption can be replaced with company-specific figures.
Suppose a service outage lasts two hours.
Staff assumptions
- 25 people affected
- Loaded hourly cost: ₦5,000
- Estimated productive capacity lost: 60%
Staff impact:
25 × ₦5,000 × 60% × 2
= ₦150,000
Transaction assumptions
During those two hours, the business would normally expect:
- 80 transactions
- Average contribution: ₦12,000 per transaction
- Estimated permanently lost transactions: 15%
Lost contribution:
80 × ₦12,000 × 15%
= ₦144,000
Recovery costs
Suppose the incident also requires:
- Emergency technical support: ₦75,000
- Overtime and reconciliation: ₦45,000
Direct recovery cost:
₦75,000 + ₦45,000
= ₦120,000
Illustrative financial impact
Staff impact:
₦150,000
Permanently lost contribution:
₦144,000
Recovery cost:
₦120,000
Estimated total:
₦414,000
That number does not include a made-up value for customer trust or reputation.
Those impacts should be recorded separately unless the organisation has an approved methodology for valuing them.
Make the Assumptions Editable
The point of the example is not ₦414,000.
The useful part is the structure.
Replace:
- 25 employees with your number
- ₦5,000 with your approved loaded hourly cost
- 60% with your estimated productivity loss
- 80 transactions with your normal volume
- ₦12,000 with your approved contribution
- 15% with your estimated permanent-loss rate
- Recovery costs with actual expected costs
The result becomes an organisation-specific scenario rather than a borrowed statistic.
Use Ranges When You Are Unsure
Sometimes a single assumption would imply more certainty than the evidence supports.
For example, perhaps the business believes permanent transaction loss is somewhere between 10% and 20%.
Calculate both.
That creates a range.
A transparent estimate of:
₦350,000–₦480,000
may be more useful than pretending the answer is precisely:
₦417,263.42
Precision is not the same as accuracy.
Why the Calculation Matters
The purpose of downtime modelling is not to frighten management.
It is to prioritise resilience.
If one business process could tolerate a day of disruption with limited impact, it may not justify the same recovery investment as another process where an hour creates significant operational harm.
The estimate can help leaders compare potential impact with measures such as:
- Backup and restore capability
- Alternate connectivity
- Redundant infrastructure
- Spare equipment
- Monitoring
- Manual fallback procedures
- Recovery testing
- Vendor escalation
That makes downtime a business-prioritisation discussion rather than only an IT incident.
A Backup Is Not the Same as Recovery
An organisation may have a successful backup and still discover that recovery takes much longer than expected.
Useful recovery tests ask:
- Can the required data actually be restored?
- How long does it take?
- Are dependent systems available?
- Can users reconnect?
- Can the business process resume?
- Is manual reconciliation required afterwards?
The business needs recovery capability.
Not merely evidence that a backup job completed.
Keep the Model Honest
A useful downtime estimate should show:
- Which service was affected
- Duration
- Number of affected people
- Productivity assumption
- Transaction assumptions
- Contribution assumption
- Permanent-loss percentage
- Recovery costs
- Contractual costs
- Non-financial impacts
- Exclusions
Another manager should be able to read the model and understand how the number was created.
If changing one assumption changes the answer significantly, that is useful information too.
It tells leadership which assumptions deserve better evidence.
The Better Downtime Question
Instead of asking:
“What does an hour of downtime cost businesses?”
ask:
“What would an hour of this specific service being unavailable cost our organisation?”
That question can actually support a decision.
And it does not require borrowing an industry average that may have little to do with your business.
