reliability
Cost of Downtime: A Founder’s Honest Calculation Guide
Calculate the cost of downtime from your own revenue path, customer impact, recovery effort, and risk. Avoid borrowed industry averages.
TL;DR — The cost of downtime is your lost or delayed value during an outage plus recovery effort and longer-tail customer consequences. Calculate it from your own workflow and assumptions; industry averages are not a decision model for your business.
Downtime cost is often reduced to revenue per hour. That is a useful first term, but it is not the whole question. A failure can block a transaction, delay a customer’s work, consume support time, require recovery engineering, create data cleanup, and weaken trust after the system returns. The cost depends on which journey failed, when it failed, and whether customers had a workaround.
Do not borrow a dramatic “average outage cost” from a vendor report and apply it to a startup. Such figures combine very different organizations and failure types. A founder can make a better decision with a transparent, local estimate that says exactly what is known and what is hypothetical.
Identify the journey that went down
Name the specific user action: checkout, sign-in, document upload, scheduled export, internal fulfillment, or a third-party integration. Then define the outage window and affected audience. A five-minute interruption in a low-traffic internal dashboard is not the same event as a five-minute failure at the end of a sales campaign.
Start with direct value delayed or lost. For a transaction flow, that may be completed purchases that could not occur. For a B2B workflow, it may be work held up until service returns. Add the cost of the response: support, engineering, incident coordination, vendor escalation, and data reconciliation. Then document possible follow-on impact separately instead of presenting it as a fact.
For a hypothetical calculation, suppose a service normally processes $600 in confirmed orders per hour, an outage lasts two hours, and the team expects half of interrupted buyers to return. The affected value is $1,200; under that assumption, $600 is estimated lost and $600 is delayed rather than lost. Add the actual recovery hours only after they happen. This is decision support, not a forecast.
Include what revenue misses
Customer impact can be more important than immediate sales. An outage may prevent a client from completing payroll, accessing a report, serving their own users, or meeting a deadline. Capture those consequences in words and, where possible, in customer-specific evidence. This protects against the false comfort of a low revenue-per-hour estimate for a high-trust product.
Consider data integrity too. A service can appear available while accepting a request twice, failing silently, or delivering stale information. Recovery may require audits, corrections, communications, and reprocessing. These are costs of the event even if the status page stayed green.
The Google SRE incident guide recommends alerting on user-facing symptoms and making alerts actionable. That principle keeps your downtime model connected to what customers actually experienced.
Use the calculation to choose protection
The goal is not to eliminate every minute of downtime at any price. Use the estimate to compare a reliability investment with the risk it reduces. A backup restore test, deployment rollback, redundant integration path, or clearer on-call owner may be a sensible investment when it protects a costly journey. A complex architecture may not be warranted for a low-impact internal convenience.
An uptime calculator can translate an availability target into a permitted amount of unsuccessful time, but it cannot set the target for you. That is the job of a service level objective: an explicit agreement about a customer-facing measure, time window, and response when the budget is consumed.
Review after the system recovers
After any meaningful event, compare the estimate with what actually happened. Record the customer impact, duration, recovery effort, and assumptions that proved wrong. Use a blameless incident postmortem to turn the evidence into owned actions, such as an alert test, a runbook change, or a product safeguard.
Over time, your own incident record becomes more useful than a market-wide statistic. It tells you which journeys are fragile, which recovery steps are slow, and which reliability investments earn their place on the roadmap. That is an honest way to make downtime visible without using fear as a budgeting tool.
Communicate before the numbers are final
During an outage, say what users can and cannot do, what workaround exists, and when the next update will arrive. Do not delay communication while calculating a final cost. Clear updates reduce confusion and give the later review better evidence about the real customer impact.