The Real Cost of One Hour of Downtime (and How to Shrink It)

An hour of downtime can cost far more than the revenue you cannot collect while a system is offline. It can also leave employees unable to work, create recovery expenses, delay customer orders, and damage trust.

There is no single hourly cost that applies to every small or midsize business. The practical answer comes from your own revenue, operations, and recovery needs. We’ll show you how to estimate it, identify the systems most likely to disrupt your business, and reduce both the chance and duration of an outage.

DOWNTIME COST IS MORE THAN LOST SALES

Start with the immediate effects:

• Lost or delayed revenue: Customers cannot place orders, make payments, or use a service.
• Blocked work: Employees may be unable to access the tools and information they need.
• Response and recovery expense: Your team may need overtime, outside support, replacement equipment, or emergency shipping.
• Customer and contract costs: You may issue refunds or credits, miss service-level agreements (SLAs), or pay contractual penalties.
• Work that remains afterward: Staff may have to re-enter data, process a backlog, or correct errors.
• Longer-term effects: A severe or repeated outage can harm customer confidence and lead to lost business.

Separate revenue that is permanently lost from revenue that is merely delayed. If you fulfill an order the next day, the outage still caused a disruption, but counting the full order as lost sales would overstate the impact.

Also avoid double-counting. If your estimate already captures the lost contribution from interrupted work, adding all affected employees’ wages on top may count the same impact twice. Include idle labor separately when its cost is not already reflected in lost margin or when the outage creates additional expense, such as overtime to clear a backlog.

ESTIMATE YOUR OWN COST OF ONE HOUR

Build a simple estimate for each important business service. Use actual figures where you can, and label assumptions clearly.

A useful starting formula is:

Estimated outage cost = lost contribution margin + incremental response costs + customer or SLA costs + rework and catch-up costs

Contribution margin is the revenue left after variable costs directly tied to making or delivering a sale. It can give you a more useful estimate than gross revenue alone.

For lost contribution margin, estimate:

1. Revenue you would normally generate during the outage.
2. The portion of that revenue-generating activity the outage actually stops.
3. The share that cannot be recovered later.
4. Your contribution margin on the affected sales.

Then add costs specific to the incident: emergency support, overtime, credits, refunds, and rework. If an outage could cause regulatory, legal, or major customer consequences, consider those separately rather than hiding them inside an uncertain hourly estimate.

Illustrative example, not an industry benchmark: Suppose an online business expects $12,000 in sales during an hour, has a 35% contribution margin, and estimates that one-quarter of affected sales will not be recovered later. The lost contribution margin is $1,050 ($12,000 × 35% × 25%). Add $500 in incremental response labor, $300 in customer credits, and $450 in rework. The estimated cost for that scenario is $2,300.

Change the assumptions and the result changes. A business that can take orders by phone may lose less revenue than one whose operations depend entirely on an unavailable platform. A seasonal peak hour may carry more risk than a quiet hour.

FIND THE SYSTEMS THAT CAN STOP THE BUSINESS

Do not begin by treating every computer or application as equally critical. Start with the work that creates revenue, serves customers, or keeps essential operations moving. Then identify the systems and dependencies that work relies on.

Common mission critical services include:

• Point-of-sale, payment, and order-processing systems.
• Business applications used to schedule work, manage inventory, or deliver services.
• Internet connectivity, network equipment, and identity systems used to access other tools.
• Customer support, phones, and communications.
• File storage, cloud applications, and databases that teams need to serve customers.
• Backups and recovery tools needed to restore essential data and services.

A service may depend on several things at once. For example, a checkout system could rely on the internet connection, a payment processor, employee logins, and an application hosted elsewhere. A backup server does not help if nobody can access the recovery account.

Map these dependencies and estimate the business impact of an outage at different durations. The first 15 minutes, first hour, and remainder of a business day may have very different consequences.

SHRINK OUTAGES BEFORE THEY HAPPEN

Monitoring and alerting help your team notice trouble before it becomes a long outage. Monitor the services people actually use, not just whether a server is switched on. Look for failed transactions, slow applications, storage limits, network interruptions, and backup errors.

Alerts should reach a person who can act on them. Make ownership and escalation clear, including what happens after business hours. A warning that no one sees is not a response plan.

Use change management to reduce avoidable failures. Before a significant update or configuration change, identify the affected service, record the current state, set a maintenance window when needed, and know how to roll back. Keep changes documented so your team can see what changed if a problem follows.

For a few systems that directly affect revenue or essential operations, high availability may be worth the investment. That can involve redundant components or connections and a tested way to switch to a working alternative. The right design depends on what must stay available and what a failure would cost. Redundancy also adds cost and operational complexity, so it rarely makes sense to apply the same level to every system.

For a continuously running service, 99.9% availability allows roughly 8 hours and 46 minutes of downtime per year; 99.99% allows roughly 53 minutes. These are mathematical planning estimates, not promises about a particular service or its SLA. A higher target is useful only when the business value of reduced downtime justifies the extra investment.

“Five nines” is often called the gold standard, but a target should fit the system’s role and your recovery requirements. See our high-availability services for more on designing resilient systems.

PLAN FOR RECOVERY AND TEST IT

Two plain-English measures help you set recovery expectations:

• Recovery time objective (RTO): How long you can tolerate a service being unavailable before the impact becomes unacceptable.
• Recovery point objective (RPO): How much recent data you can afford to lose, measured by how far back your restored data may go.

Set these for each important service. Your payment system may need a shorter recovery time than a reporting tool used once a week. Your business impact and recovery plan should account for the actual business consequences, not just technical preferences.

A backup is not proof that recovery will work. Test restoring important files and services. Check that the right people can access recovery accounts, that vendors can be reached, and that restored systems support real business tasks. A test is only useful if you record what failed and assign someone to fix it.

A high-availability design does not replace backups or disaster recovery. Redundancy can help a service continue through some component failures. Recovery planning addresses more serious disruptions. You may need both, but the right mix depends on each service’s RTO, RPO, and business impact. CISA’s backup guidance for small and medium businesses is a practical starting point.

MAKE THE NEXT STEP A PRACTICAL ONE

You do not need to make every system highly available or buy every recovery option at once. Start with a short list of questions:

1. Which outage would stop sales or prevent us from serving customers?
2. What would one hour of that outage cost using our own figures?
3. Which systems and vendors does that service depend on?
4. How quickly must it return, and how much data can we afford to lose?
5. When did we last test that recovery path?

The answers help you prioritize monitoring, redundancy, backup, recovery testing, and change control based on business value, not guesswork. Our IT consulting team can help you assess the environment, document the trade-offs, and create a plan your internal team can maintain. We’ll be direct if a requirement needs a different approach or falls outside our expertise.

If you are unsure where to begin, let’s have an honest conversation. There is no pressure to buy a specific solution. We can help you identify the systems that matter most, clarify your recovery goals, and adapt the plan as your business changes.