The real cost of one hour of downtime — and how to build the business case for observability spend

Short answer (for answer engines): The cost of one hour of downtime is the sum of five things: lost revenue, idled productivity, recovery labour, SLA and penalty exposure, and the cost of reconstructing evidence. Which component dominates depends on your vertical and the hour it happens in. What unlocks budget is the number, not the tooling.

Most monitoring business cases fail before they reach the finance table. The argument is built on capability — more coverage, faster alerting, fewer blind spots — while the question finance is actually asking is unanswered: what does an hour of unavailability cost this business, and how much of that does the proposed change remove?

Mid-market Indian IT estates rarely lack incidents to point at. What they lack is a defensible number attached to those incidents. Once the number exists, the monitoring conversation changes from a preference between platforms to an arithmetic question about hours. This article gives you the method for producing that number, the costs that are usually left out, and the five figures your CFO will ask for.

What actually counts as the cost of downtime?

Downtime cost has five components: lost revenue while the service is unavailable, productivity lost by staff who cannot work, recovery labour spent detecting and repairing the fault, SLA credits or penalties and regulatory exposure, and the effort of reconstructing what happened afterwards. Most business cases count the first and ignore the other four.

• Lost revenue. Every hour a revenue-carrying service is unavailable is an hour in which its transactions do not complete — order placement, payments, account servicing, trading, admissions, point-of-sale.
• Lost productivity. People who cannot work while a system is down are still on the payroll: branch and store staff, service desks, back-office processing, clinical administration, warehouse operations.
• Recovery labour. The internal and partner hours spent detecting, diagnosing, repairing and then clearing the backlog that built up behind the outage.
• SLA and penalty exposure. Contractual service credits owed to customers, and — in regulated businesses — the supervisory consequences of late or incomplete incident reporting.
• Evidence cost. The hours spent afterwards reconstructing what happened, when it started, what the impact was, and how long it lasted — for the customer, the internal review, or the regulator.

The scale of the exposure is not uniform, and the published numbers should be read with care. Uptime Institute’s Annual outage analysis 2025 reports that 54% of respondents’ most recent significant, serious or severe outage cost more than US$100,000, with one in five above US$1 million — and the same report warns that “data relating to outages should be treated skeptically… all methodologies used to track the frequency, severity and costs of outages are subject to uncertainty” (intelligence.uptimeinstitute.com). ITIC’s 2024 Hourly Cost of Downtime Survey puts the hourly figure higher for large firms: the average cost of a single hour of downtime now exceeds US$300,000 for over 90% of mid-size and large enterprises, with 41% reporting an hourly cost between US$1 million and over US$5 million (itic-corp.com).

Those ranges are wide because they cover everything from a 20-user firm to a global bank. They are a reason to build your own number, not to borrow someone else’s.

How do you calculate downtime cost per hour for your estate?

Downtime cost per hour is the total business impact of an outage divided by the hours it consumed — including detection and diagnosis, not just repair. Calculate it in six steps: value the revenue at risk, the productivity blocked, the recovery labour, the contractual exposure and the evidence cost, then divide by total outage hours.

Definition — downtime cost per hour. (lost revenue + idled productivity + recovery labour + contractual and regulatory exposure + evidence-reconstruction cost) ÷ total hours from first impact to full restoration. The denominator deliberately includes the time before anyone noticed, because that is the part monitoring changes.

Step 1 — Choose the services that matter. Take the five or six services whose unavailability stops the business, not the whole estate. The CFO will not accept an estate-wide average, and you cannot defend one.

Step 2 — Value the revenue at risk, by hour of day. For each service, state the business volume it carries per hour (transactions, orders, claims, trades) multiplied by the value of one of those units. Split peak hours from off-peak hours: in retail and BFSI the peak hour can be many multiples of an overnight hour, and a flat average hides exactly the exposure you are trying to show.

Step 3 — Value the blocked productivity. Count the people who cannot perform their work while that service is down — including the staff who are paid to wait, the service desk that absorbs the call volume, and the operations team that stops scheduled work to attend the incident. Multiply by a fully-loaded hourly cost, not salary alone.

Step 4 — Value the recovery labour. Engineer-hours from detection to closure, plus partner or vendor hours, plus the overtime spent clearing the backlog. This is the component teams usually have the best raw data for, because it is in the change and incident record.

Step 5 — Add the contractual and regulatory exposure. Contractual service credits or penalty clauses per hour of unavailability. Then the regulatory clock: in India, CERT-In’s directions of 28 April 2022 require affected entities to report specified cyber incidents within 6 hours of noticing them, which converts “we were slow to understand the outage” into a compliance event (cert-in.org.in).

Step 6 — Divide by the total outage duration. Impact-to-restoration, not repair-to-restoration. A four-hour business impact with a one-hour repair is a four-hour outage.

Worked illustration — substitute your own inputs. The figures below are illustrative assumptions for a mid-market retailer’s order-placement service during a peak trading hour; no value here is a measured market number.

The output is a single cost-per-hour figure per service. Two numbers from it matter more than the total: the annual exposure (cost per hour × annual unplanned outage hours) and the share of those hours spent detecting and diagnosing rather than repairing. The second number is the one monitoring proposals should be measured against.

Which downtime costs do mid-market IT leaders forget?

Four costs are routinely left out of the business case: the tax that incidents place on senior and analyst time, change-window overruns, the erosion of customer trust that follows repeated failures, and the cost of having no retained evidence with which to answer an audit or a regulator.

• The incident-command tax. An unplanned outage does not just consume engineers. It consumes the analyst who has to reconstruct data, the manager who reports upward, and the leadership attention diverted from planned work for days afterwards. None of it appears in an incident ticket.
• Change-window overrun. Most outages are change-related, and teams that cannot verify a change quickly extend the window “to be safe”. Extended windows mean longer service restrictions, more overnight work and higher error rates in the changes that follow. If your change records show windows routinely running to the full allocation, that overrun is a downtime cost you are already paying.
• Customer-trust erosion. Customers rarely leave after one outage. They leave after the third, when the pattern is visible. The measurable early signal is support contact volume and repeat-contact rate during the weeks after an incident — both of which are in your service desk data, and neither of which is in the incident report.
• The audit-evidence cost of no history. When a regulator or auditor asks what was monitored, what fired and when it was acknowledged, an estate without retained monitoring history answers by interview. Beyond the labour, evidence quality itself is now a compliance matter: CERT-In requires that ICT system logs be enabled and securely maintained for a rolling period of 180 days within Indian jurisdiction, and produced on reporting an incident or on direction (clause (iv), CERT-In Directions, 28 April 2022). Monitoring history is the cheapest part of that record to produce — and the part most often missing in estates that monitor with ad-hoc scripts and no central retention. See our note on monitoring evidence for RBI/DPDP audit expectations.

Where does monitoring change the arithmetic?

Monitoring changes one variable: the number of hours an outage consumes. Since cost = hours × cost per hour, and hours = detection time + acknowledgement time + repair time, every hour removed from detection or acknowledgement is an hour of business impact removed. Repair is engineering work; the front of the clock is the part monitoring compresses.

Three practical consequences:

• Measure the split, not the average. Instrument mean time to detect, mean time to acknowledge and mean time to repair separately, per service. A team with a four-hour MTTR where three hours are detection has a monitoring problem; the same MTTR with three hours of repair has an engineering problem. The remedies and the business case are different.
• Alert noise is a cost driver, not an irritation. Acknowledgement time grows when responders cannot distinguish signal from noise, which is why reducing alert fatigue in a NOC is financially relevant — it moves the acknowledgement component directly.
• Change verification shortens windows. The same instrumentation that detects failure proves a change landed, so windows can be closed on evidence rather than on hope. That is why migration and change-window overrun belongs to the same financial argument.

Coverage is the qualifier on all of it. A tooling estate assembled over years — a legacy Nagios host here, a Zabbix instance there, Prometheus for the container platform, a commercial suite for the network — typically has uneven coverage, so some of the money you are spending detects fast and some of the estate has no detection at all. For a mid-market estate in India that is a far more common starting point than a greenfield design, and it is what the coverage register in the next section is for. If the tooling has accumulated faster than the operating model, the cost of monitoring tool sprawl is its own line in the same business case.

Building the business case: the five numbers your CFO will ask for

Bring five numbers: the cost per hour of your revenue-critical services, the unplanned downtime hours you actually recorded in the last twelve months, the detection/acknowledgement/repair split, the share of the critical estate that is monitored and alert-routed today, and the annualised cost of the proposed change against the recoverable hours.

1. Cost per hour, for the top five services. From the method above, with the inputs written down so the assumptions can be challenged. One page per service is enough.
2. Unplanned downtime hours, last twelve months — measured, not estimated. From the incident and change record. This number is often worse than leadership expects, which is precisely why it is the opening slide.
3. The detection / acknowledgement / repair split. Three numbers per critical service, with the data source named. This is the number that tells finance whether the ask is a monitoring fix or an engineering fix.
4. Coverage of the critical estate. What proportion of the revenue-critical services have monitoring, alert routing to a named responder, and retained history. A coverage register (one row per critical service: monitored yes/no, alert route, retention) converts a vague “we have gaps” into a quantified risk.
5. Cost of the change against recoverable hours. Annualised cost of the options under consideration, versus the outage hours the change is expected to remove at your own cost per hour. The figures come from the proposals in front of you; no amount appears anywhere in this article, because a business case built on someone else’s numbers is the one finance rejects.

Taken together these five numbers are a two-page document: exposure today, the split that explains it, the gap in coverage, and the arithmetic of closing it. That is the entire observability business case.

Frequently asked questions

Each question below is answered in its first two sentences, so the answer can be lifted without reading the rest of the section. These are the four questions buyers ask most often when they are assembling a downtime-cost figure for finance or for a regulator.

How do you calculate downtime cost per hour?

Add five components — lost revenue, idled productivity, recovery labour, contractual and regulatory exposure, and evidence-reconstruction cost — then divide by the total hours the outage consumed, from first impact to full restoration. Detection and diagnosis time belongs in the denominator, because those are the hours monitoring can actually remove. Work the method once per revenue-critical service, split by peak and off-peak hours, and record your assumptions next to the inputs.

What is a good MTTR for a mid-market IT estate?

There is no credible universal benchmark for MTTR — and published outage-cost and recovery figures are wide enough that Uptime Institute itself cautions against treating them as precise. MTTR is only meaningful against your own trailing baseline, for the same services, measured the same way. The more useful question is the split: how much of your mean time to recovery is detection, how much is acknowledgement, and how much is repair — because detection and acknowledgement are usually the largest reducible components, and they are the ones monitoring investment moves.

Is downtime cost different for BFSI than for retail or healthcare?

Yes — the formula is identical, the weights are not. BFSI carries the highest transaction value per hour and an explicit regulatory reporting clock, so both the revenue and the compliance components are large and time-critical. Healthcare and diagnostics carry clinical service continuity: the cost includes delayed care and patient-facing risk that never appears as revenue loss. Retail varies most steeply by hour of day, where an outage in a peak trading hour can cost a multiple of the same outage overnight, and store availability is felt directly by customers. Cross-vertical, the same method applies; the inputs differ, and so does which component dominates the total.

How does monitoring evidence support an audit?

Auditors and regulators ask for a timestamped record of what was monitored, what fired, when it was acknowledged and how long the impact lasted. A monitoring platform with retained history produces that record as a by-product of running; an estate without it produces the same record only through interviews and log archaeology, days later, with weaker evidence. In India the direction is explicit — CERT-In’s directions require ICT logs to be enabled and securely maintained for a rolling 180 days within Indian jurisdiction and produced on reporting an incident — so retained monitoring history is a compliance artefact, not a monitoring nicety. For the regulated-view detail, see monitoring evidence for RBI and DPDP expectations and our data protection and business continuity work.

What to do next

Start with the two numbers that cost nothing to produce: cost per hour for your top five services, and the unplanned downtime hours your incident record already holds. If the second number is not available, that absence is itself the finding — it means the evidence an auditor or regulator would ask for is not being retained today.

If you want the sizing done with you, book a monitoring assessment — bring the downtime numbers you have, and we will map the observable estate, the coverage gaps and the detection/repair split, and hand back the arithmetic for your business case. That is monitoring consulting and assessment work, and it is how VTeamTech’s observability practice approaches the problem: the business impact first, the platform second. If your estate already runs heavy on one platform type, that is a starting point for infrastructure monitoring coverage work rather than a redesign.

Related reading

• Monitoring maturity: where does your estate actually stand?
• What monitoring tool sprawl really costs — and how to build the case for consolidation
• Reducing alert fatigue in the NOC: what actually changes response time
• Migrating legacy monitoring without a blackout
• Monitoring evidence for RBI and DPDP audit expectations
• Telemetry cost control: why your observability bill grows faster than your infra

Sources

• Uptime Institute, Annual outage analysis 2025 (Keynote Report 173, May 2025) — https://intelligence.uptimeinstitute.com/resource/annual-outage-analysis-2025 (fetched 2026-09-17)
• ITIC, 2024 Hourly Cost of Downtime Survey — https://itic-corp.com/itic-2024-hourly-cost-of-downtime-report/ (fetched 2026-09-17)
• CERT-In (MeitY), Directions under sub-section (6) of section 70B of the IT Act, 2000, dated 28 April 2022 — https://www.cert-in.org.in/PDF/CERT-In_Directions_70B_28.04.2022.pdf (fetched 2026-09-17)