How to Calculate the Cost of E-commerce Downtime (Formula and Example)

"Downtime is expensive" is true and useless. What helps is a number for your store: what an hour of outage costs on a Tuesday afternoon, on a Saturday evening and during a sale. With that number you can decide how much monitoring, redundancy and on-call effort is worth paying for. This guide gives a formula you can fill in from your own analytics, a worked example with made-up figures, and the costs people forget.

The basic formula

Start with the revenue you would normally have earned during the outage:

lost revenue = normal hourly revenue x outage hours x (1 - recovery rate)

• Normal hourly revenue is what the store typically makes at that hour and weekday, not the daily average divided by 24. Traffic is lumpy: a store that makes most sales between 7 pm and 10 pm loses far more in those hours than at 4 am.
• Outage hours is measured from when the problem started to when checkout worked again, not from when you noticed. The gap between the two is detection delay, and it is the part monitoring shrinks.
• Recovery rate is the share of lost orders that come back later. Some shoppers return after the site is up and buy anyway; others buy from a competitor. For commodity products with many alternatives it is low. For unique products, repeat customers or subscription renewals it can be high. You can estimate it by comparing the hours after past outages with a normal baseline, and if you have no data, run the calculation at 0 percent and at a cautious guess and show both numbers.

Where to find your inputs

1. Revenue by hour and weekday. Export orders from your store platform for the last 90 days and group by hour of day and day of week. A spreadsheet pivot table is enough.
2. Sessions and conversion rate. Hourly sessions multiplied by conversion rate and average order value should roughly match hourly revenue. If it does not, one of the figures is wrong.
3. Average order value (AOV) और gross margin. For decision-making, use margin as well as revenue: lost revenue overstates the profit lost, while fixed costs continue regardless.

Costs that are not lost sales

Lost orders are the visible part. Add the rest:

A defensible estimate uses the first six rows and calls out the last one as "not included".

Worked example

Imagine a small store with these assumptions. They are invented for illustration.

• Typical Thursday evening (7 pm to 9 pm) revenue: 400 per hour.
• A payment problem breaks checkout from 7:10 pm to 9:10 pm. That is 2 hours of outage.
• Detection: nobody noticed until a customer emailed at 8:20 pm, so the store was blind for 70 minutes.
• Recovery rate: the owner estimates 25 percent of the lost orders come back, based on how sales behaved after a previous short outage.
• Ad spend that evening: 30 per hour, running throughout.
• Two people spent 3 hours each fixing and following up, at a loaded cost of 25 per hour.
• Support handled 12 extra tickets at about 10 minutes each, at 20 per hour.

Calculation:

lost revenue      = 400 x 2 x (1 - 0.25)         = 600
wasted ad spend   = 30 x 2                       = 60
staff time        = 2 people x 3 h x 25          = 150
extra support     = 12 x (10/60) h x 20          = 40
------------------------------------------------------
estimated cost                                    = 850

Now look at what monitoring would change. With a check every 5 minutes and an alert to a phone, detection might take 5 to 10 minutes instead of 70. If the fix still takes the same effort, the outage would have lasted roughly 1 hour instead of 2, and the sums become:

lost revenue      = 400 x 1 x (1 - 0.25)         = 300
wasted ad spend   = 30 x 1                       = 30
staff and support                                 = 190 (largely unchanged)
------------------------------------------------------
estimated cost                                    = 520

The difference, 330 for a single incident, is the value of faster detection in this made-up scenario. If outages like it happen several times a year, the comparison against the cost of monitoring is easy. Notice also that margin was not applied. If the gross margin were 40 percent, the profit lost on the sales alone would be 40 percent of the 600, while the ad, staff and support costs are real cash out the door.

Margin or revenue: which number to use?

• Use revenue when you want a simple, comparable figure, or when explaining the scale of the problem to people outside the business.
• Use gross margin for business cases: "will this investment pay back?" Fixed costs continue whether the site is up or not.
• Use both, labeled clearly, in postmortems.

Cost per incident versus cost per year

Multiply the per-hour figure by the downtime you actually experience. Your monitoring history gives the data: total minutes of downtime in the last year from your uptime monitor. If you do not have one yet, start now, and in the meantime estimate from incident tickets. Uptime percentages explained converts a target such as 99.9 percent into minutes, so you can compare allowed downtime with its price.

For a store whose peak hour revenue is high, the allowed downtime at a given uptime target is not distributed evenly: a 40-minute outage at peak costs far more than the same outage at 4 am. Add a column to your spreadsheet with revenue at each hour so you can see when downtime is most costly, and keep deployments and risky changes out of those windows.

What reduces the cost

Cost scales with detection time plus repair time, so attack both.

1. Detect faster. Checks every few minutes with alerts that reach a person. See how often to monitor a website. Confirm failures with a second check to limit false alarms, as covered in how to reduce false alerts.
2. Monitor the revenue path, not just the home page. A home page can return 200 while checkout is broken. Use a keyword check on the cart or checkout page and monitor payment webhooks; see payment gateway downtime monitoring.
3. Repair faster. Keep a short runbook for the usual failures: payment provider outage, expired certificate, DNS change, plugin update. Rehearse before sales.
4. Communicate. A status page reduces repeated support questions during an incident.
5. Avoid self-inflicted outages. Most downtime follows a change. Freeze changes before major sales; the Black Friday readiness checklist has a timeline.
6. Learn from each incident with a short postmortem.

अगले कदम

• Start measuring with the uptime monitor.
• Share status during incidents with a status page.
• Add checks for the checkout path: payment gateway downtime monitoring.
• Plan peak periods with the Black Friday readiness checklist.
• Quantify targets with uptime percentages explained.

सामान्य प्रश्न

How do I estimate downtime cost if I have no history?

Use the last 90 days of order data to get revenue per hour, then run the formula at several recovery rates, from zero to a cautious guess. Present the range instead of a single figure, and say which inputs are assumptions.

Should I include lost customer lifetime value?

Keep it as a separate line. It is real, but it is hard to measure for a single incident. Including it in the headline estimate makes the number easy to dispute.

Is average daily revenue divided by 24 a good hourly figure?

Not really. Sales are concentrated in certain hours, so an average understates a peak-hour outage and overstates a night-time one. Use revenue for the specific hours affected.

Does the cost include the time spent before anyone noticed?

Yes. Detection delay is part of the outage from the customer's point of view. It is also the easiest part to reduce with automated monitoring.

Do partial outages count?

Yes, but weight them. If checkout fails for half of visitors, estimate the share affected and apply it to lost revenue, rather than treating the whole hour as lost or as fine.

यह पेज सामान्य जानकारी है, जिसे हमारी संपादकीय टीम ने लिखा है और दस्तावेज़ीकरण बदलने पर अपडेट किया जाता है। सर्वर और प्रदाता अलग-अलग होते हैं, इसलिए बदलाव पहले सुरक्षित तरीके से जाँचें। देखें: संपादकीय नीति और अस्वीकरण.