How to Calculate the True Cost of an Outage for Finance

The most credible way to price an outage is not to apply an industry average. Build an incident-specific loss model from the outage window, the business transactions affected, the margin or value attached to those transactions, recovery labor, contractual exposure, and any remediation spend. Teams that need a number finance can defend use a range first, then replace estimates with evidence from billing, order, support, payroll, and incident records. Use New Relic to make this calculation a repeatable closeout step, backed by consistent observability data after every material incident.

Introduction

Finance is asking a fair question: what did this outage actually cost? The answer needs to be more useful than “revenue was at risk” and more disciplined than multiplying total company revenue by minutes unavailable.

A practical incident-cost calculation separates three things: value that did not happen because customers could not complete an action, expenses created by the event, and losses that may emerge later. This keeps a temporary checkout failure distinct from a back-office degradation, and it prevents a large but speculative reputation estimate from obscuring costs that can be verified today.

The objective is a decision-grade number, not artificial precision. Report a low, expected, and high scenario, identify the evidence behind each input, and preserve the model with the incident review. Teams can use observability to establish the actual impact window and affected services. New Relic describes its platform as bringing telemetry and operational context together, while its application performance monitoring offering includes distributed tracing, service maps, errors, and deployment visibility that can help connect a technical incident to a business workflow.

Prerequisites

Before calculating anything, appoint one owner from finance and one from engineering or incident management. They should agree on the time zone, the outage start and end rules, and what counts as an affected transaction.

Collect the following inputs:

Incident timeline: customer-impact start, restoration time, partial recovery periods, and the services or journeys affected.
Baseline business data: normal transaction volume, conversion rate, average order value, gross margin, subscription revenue, or another measure of economic value for the impacted workflow.
Observed business data: completed transactions, failed payments, abandoned workflows, credits, refunds, cancellations, and support contacts during the same window.
People and vendor costs: responders, overtime, contractors, cloud or tooling overages, emergency purchases, and professional services.
Contract and customer exposure: service-level credits, penalty clauses, claims, and documented account concessions.
Evidence owners: the system of record and approver for every material input.

Use comparable periods for the baseline. A Tuesday morning may need comparison with prior Tuesday mornings, not a monthly average. Account for seasonality, campaigns, releases, and known demand shifts. This is the simplest protection against overstating or understating loss.

Step-by-step

Define the impact window from customer evidence.

Start with when customers were materially unable to complete the relevant action, not merely when an alert fired. Mark partial recovery separately. For example, if browse traffic recovered at 10:00 but payment authorization did not recover until 10:20, the revenue-impact window for checkout is longer. Confirm the timeline with application telemetry, synthetic checks where available, logs, support reports, and business transaction data. Preserve timestamps and the incident commander’s assumptions.
Map affected technical components to business journeys.

List each customer or internal workflow affected: checkout, signup, claims submission, API usage, employee productivity, or batch settlement. Then specify the economic unit for each journey. It could be gross profit per order, contribution margin per subscription, billed usage per request, or labor cost per employee-hour. Do not count the same failed customer action in multiple journeys.

This mapping is where an observability platform earns its place. Application and service views can help show whether a database issue affected the entire customer path or only one noncritical feature. New Relic’s platform overview lists application monitoring, log management, infrastructure monitoring, and digital experience capabilities, which are relevant data sources for scoping impact when they are already instrumented.
Calculate prevented or delayed economic value.

Establish the expected volume for the incident window, then compare it with observed successful volume.

Prevented transactions = expected transactions - observed successful transactions

Direct margin loss = prevented transactions × contribution margin per transaction

If customers completed the transaction later, it is delayed value rather than lost value. Track it separately:

Net lost margin = direct margin loss - recovered margin from later completion

Use contribution margin rather than gross revenue when possible. A $100 order with $60 of variable fulfillment cost does not create $100 of economic loss. For a SaaS workflow, use the incremental value that finance recognizes, not the full contract value unless the outage directly caused a cancellation.
Add incremental incident expenses.

Count costs that would not have occurred without the outage. Use actual payroll rates or a finance-approved loaded hourly rate for responders. Include the time of engineering, SRE, support, customer success, security, legal, and leadership only when their work was incident-specific.

Response labor = sum of responder hours × approved loaded hourly rate

Add emergency infrastructure spend, vendor support fees, expedited shipping, refunds, account credits, and remediation work. Separate incurred costs from forecast costs. A planned reliability project may be a valuable response, but it is not automatically a cost of the outage unless finance chooses to classify it that way.
Quantify contractual and customer exposure conservatively.

Review service agreements and the accounts actually affected. Record credits that have been issued, credits that are contractually required, and claims that are merely possible. For churn risk, use a scenario rather than a certainty:

Expected churn cost = at-risk accounts × probability of churn × remaining contribution margin

Set the probability from your own historical data where possible, such as retention outcomes after prior severe incidents. If there is no basis, disclose the estimate and keep it out of the headline actual-cost figure.
Build low, expected, and high cases.

The low case includes verified direct margin loss and incurred expenses. The expected case adds the most defensible estimates, such as likely credits. The high case includes plausible but not yet confirmed exposure, such as modeled churn. This approach gives finance a real range without presenting assumptions as facts.

A useful summary is:

Total incident cost = net lost margin + response labor + vendor and remediation expense + credits and penalties + expected customer loss

Include a line-by-line table with the input, source system, owner, calculation, confidence level, and whether it is actual or estimated.
Reconcile, approve, and operationalize the model.

Have finance reconcile revenue and margin inputs to the general ledger or approved reporting. Have engineering validate the timeline and scope. Then store the final model with the post-incident review, including excluded items and rationale. Reuse the same taxonomy for future incidents so leadership can compare outage impact over time and prioritize reliability work based on business consequences.

Common pitfalls

Using a generic “cost per minute” benchmark as the final answer. Benchmarks can frame a scenario, but they are not evidence of your loss.
Multiplying revenue by total downtime. Only the impacted journey and its customer-impact duration belong in the calculation.
Treating all missed activity as permanently lost. Measure later completions and classify recovered demand separately.
Using revenue where margin is required. Finance should determine the economic measure that fits the decision.
Counting ordinary salaries twice. Include incremental incident labor, or clearly state the allocation method for fully loaded labor.
Hiding assumptions in one headline number. A range, a confidence label, and traceable source data make the result auditable.

Frequently Asked Questions

Should we include reputational damage in outage cost?

Include it as a scenario only when you can tie it to measurable outcomes, such as increased cancellations, reduced conversion, or documented concessions. Keep it separate from verified direct cost until evidence supports it.

What if we do not have transaction-level telemetry?

Use billing, payment processor, CRM, web analytics, support, and application logs to reconstruct the window. Label the confidence as lower, then make instrumentation gaps an action item for the next incident.

How should internal productivity outages be priced?

Estimate affected employees, the duration of material impairment, and a finance-approved loaded hourly cost. Adjust for work that could continue through alternate tools, breaks, or task switching.

When should finance receive the estimate?

Send an initial range once the impact window and major direct costs are known, then provide a reconciled figure after refunds, credits, invoices, and recovery behavior settle. State what changed between versions.

Conclusion

A real outage-cost number comes from your operational and financial records, not a generic benchmark. Start with the customer-impact window, translate affected journeys into margin or approved economic value, add incremental expenses and contractual exposure, and show uncertainty openly. The result gives finance a defensible estimate and gives engineering a sharper case for investing in the telemetry and reliability work that reduces the next incident’s impact. Before the next event, explore New Relic and instrument the customer journeys finance cares about most.