How much does one hour of downtime cost your business?

While infrastructure is working, it looks like an item in the expense report that you want to cut. Once it fails — the tone flips: engineers ask for a budget for “proper reliability”, the CFO looks at the estimate, and no one can explain why that exact amount is needed and not half as much.

The conversation stumbles over one missing number: how much money the company loses per hour of downtime. Until it exists, both sides argue on beliefs. Once it appears, the argument becomes arithmetic.

What downtime looks like when nobody calculated it

A typical story of a growing online store. The company launches a major ad campaign for the first time: traffic bought, landing pages prepared, sales team reinforced for the weekend.

Traffic comes — and the site stops responding. The single server running everything at once can’t handle the load: user-uploaded files filled the disk, memory exhausted, the database stopped accepting connections. The developer restarts the server manually — once, twice, three times. The system comes up for a few minutes and crashes again.

By evening everything is fixed. In the morning the question arises: how much did it cost? And it turns out nobody can answer. Only the advertising budget is known — it was accounted for because it went through a contract. Everything else dissolved.

Meanwhile the real damage consisted of four components at once, and the ad budget was not the largest among them.

A formula you can calculate in half an hour

Loss from downtime = direct lost revenue + cost of team downtime + lost customers + reputation recovery costs

Let’s break down each term — they must be calculated differently.

1. Direct lost revenue

Take revenue per hour and multiply by the share of scenarios that stopped working.

The key word is “share”. A failure is rarely total. If payment doesn’t work but the catalog opens, you lose almost all revenue: the customer reached checkout and couldn’t pay. If the recommendation block failed, losses will be a few percent. If the admin panel is down, you don’t lose direct revenue at all — you lose employees’ time, which is the next term.

Here you also account for the nature of demand. Some orders will be postponed: the customer will return in an hour and still buy. Some will be lost forever — especially where decisions are impulsive or where a competitor with the same product is nearby. The ratio is different for every business, but assuming everyone will come back is self-deception.

2. Cost of team downtime

During an incident not only servers stop working. The sales department can’t process orders, support is busy with repetitive complaints instead of its regular work, marketing watches paid traffic being sent to a non-working site.

This is calculated simply: the sum of hourly rates of everyone who can’t do their job multiplied by the duration of the outage. This figure usually turns out surprisingly large — because it includes not only engineers.

3. Lost customers

The most dangerous and most underestimated part. A user who saw an error instead of payment does not always come back.

This requires methodological care. The temptation to multiply the number of lost customers by lifetime value (LTV) and get an impressive figure is strong, but that calculation overstates the damage: LTV is revenue over years ahead, not today’s loss, and it already includes retention costs. It’s more correct to calculate: number of lost customers × their gross margin over a realistic horizon (one to two years), discounted to present value.

Keep this amount as a separate line, not mixed with direct losses. It has a different nature: direct revenue is lost during the incident, customers are lost over the next year.

4. Recovery costs

Compensations and promo codes “for the inconvenience”, support work to process complaints, manager time explaining to partners, and in some cases — penalties under contracts if you committed to availability.

Not all hours are worth the same

This is the point where the calculation most often breaks. Average revenue per hour is a poor basis: real losses depend on when the failure happened.

An hour of downtime at four a.m. on Tuesday and an hour during peak sale differ by an order of magnitude, sometimes by two. For a business with seasonal demand, three weeks a year can produce half the annual revenue — and those three weeks determine infrastructure requirements.

So calculate two numbers: cost of a normal hour and cost of the worst hour in the year. The first is needed to assess annual risk, the second to understand which scenario is unacceptable under any circumstances. Decisions about redundancy are made based on the second.

If you don’t have analytics

Precision here is not important — order of magnitude is. If you don’t have end-to-end analytics, estimate from below: average order value × average number of orders per hour during working time. The resulting figure will be understated because it doesn’t account for delayed demand or reputation, but for the first conversation it’s enough.

An estimate like “about 40,000 rubles per hour” is incomparably more useful than no estimate. It immediately rules out some solutions as obviously excessive and others as obviously insufficient.

From an hour to a year

The cost per hour by itself doesn’t justify a decision. Compare annual figures: how much the solution costs per year versus how much you expect to lose per year.

Expected annual loss = cost of an hour of downtime × expected number of hours of downtime per year.

The second multiplier is taken from target availability:

The difference between 99.9% and 99.99% on paper is hundredths of a percent. In practice it’s the difference between an on-call engineer and fully automatic failover — that is, two different levels of infrastructure maturity and two different budgets.

Example. An hour of downtime costs 40,000 ₽. Right now you operate at about 99.5% — that’s around 44 hours of downtime per year, so the expected loss is about 1.7M ₽. Moving to 99.95% reduces downtime to 4–5 hours and loss to 200k ₽. The saving is roughly 1.5M ₽ per year. If the proposed solution costs 400k ₽ per year, it pays off. If it costs 4M — it doesn’t, and no arguments about the right architecture will change that.

The argument works both ways

That’s why you should calculate the number even when you’re confident in the answer.

If it’s large — you gain a justified budget to present to the CFO. Not “we need a cluster because it’s the right thing”, but “we’re losing 1.7M per year, the solution costs 400k”.

If it’s small — you get a polite way to reject an excessive proposal. When an hour of downtime costs 5,000 rubles, and a geo-distributed architecture requires 2 million to implement and 300k monthly, it’s cheaper for the business to be down a few hours a year. This isn’t negligence, but a conscious decision — provided it’s made with a number in hand, not by oversight.

What to do this week

1. Calculate revenue per hour for a normal day and for a peak day. Two numbers are enough.
2. List the revenue-producing scenarios, and estimate what share of revenue each scenario’s failure kills. Five lines, no more.
3. Ask finance for the total hourly cost of employees who stop working during an incident.
4. Pull the incident history for the year. How many hours were you actually down? That is your real availability — it’s usually noticeably lower than what’s assumed internally.
5. Multiply and get the expected annual loss. With that figure you can return to the architecture discussion.

Next is to decide what level of fault tolerance that number justifies — a separate analysis: Four levels of fault tolerance.

If you need help calculating this together and understanding what it means for your infrastructure — write to us.