The cost of downtime is almost always underestimated because business owners only count the visible part: the sales you obviously missed while the site was down. That is real, but it is usually the smaller piece. The bigger piece is the staff standing idle because the internal system they depend on is unreachable, the customer promises you cannot keep because the order in the system does not match reality, and the scramble afterward to reconcile everything that happened during the outage window. Add it up honestly and most companies find their real hourly downtime cost is two to three times what they assumed.
I ask every client the same question before we talk about backups, SLAs, or redundancy budgets: what does one hour of your main system being down actually cost you, in rupiah, right now. Almost nobody has calculated it. That number, once you have it, reframes every conversation about how much reliability is worth paying for.
Build your own downtime cost formula
You do not need a consultant to calculate this. You need about twenty minutes and your own numbers.
Lost revenue per hour. Take your average revenue during your busiest operating hours and divide by the hours in that window. If your business does Rp 300 million in an 8-hour operating day, that is roughly Rp 37.5 million per hour, though this varies significantly by hour, so use your peak-hour number if the outage risk is highest during peak.
Idle staff cost per hour. Count everyone whose job stops when the system is down, not just the people directly using it. A warehouse team that cannot process orders, a sales team that cannot check stock, a finance team that cannot process payments. Multiply headcount by average hourly wage cost, including benefits, not just base salary.
Recovery cost. This is the part people forget entirely. After the system comes back, someone has to reconcile what happened during the outage, orders taken manually that need re-entry, payments that need to be matched, customers who need to be called back. Estimate this as a multiple of the outage duration, in my experience it typically runs 1.5x to 3x the outage length in additional labor hours afterward.
Trust cost. Hardest to quantify, real nonetheless. A customer who could not check out during a flash sale, or a partner whose delivery commitment you broke because your ordering system was down, does not always come back, and does not always tell you why. Conservative approach: assume a small percentage of affected customers churn permanently and price that against their typical lifetime value.
A worked example
A multifinance company processing loan applications through an internal system found their number this way:
| Cost category | Calculation | Hourly cost (IDR) |
|---|---|---|
| Lost processing revenue | Avg approved applications/hour x avg fee | 45,000,000 |
| Idle staff (28 people) | 28 x avg hourly cost | 8,400,000 |
| Recovery labor (2x outage length) | Applies after system restored | 16,800,000 |
| Trust cost (conservative estimate) | Small % of affected applicants lost | 12,000,000 |
| Total per hour of downtime | ~82,000,000 |
Before this exercise, their internal estimate of downtime cost was "a few million an hour, mostly lost fees." The real number was roughly fifteen times higher once idle staff, recovery labor, and trust erosion were counted honestly. That gap is the entire reason this calculation matters: it changes what reliability investment looks justified.
What this number should change
Once you have your real hourly downtime cost, three decisions get easier to make with clear eyes instead of guesswork.
- Backup frequency and disaster recovery spend. If an hour of downtime costs Rp 80 million, spending a few million a month on proper backups and a tested recovery plan is not a cost center, it is cheap insurance with an obvious payback.
- SLA terms with vendors and hosting providers. A hosting contract with no uptime guarantee, or a vague "best effort" clause, looks very different once you know what an hour of their failure actually costs you.
- Maintenance and upgrade budgets. Deferred maintenance that eventually causes an outage is not free just because nothing broke yet. Price the risk against your real hourly number, not against the sticker price of the maintenance itself.
This same downtime math should also inform how seriously you take understanding your cloud bill, since a lot of "unnecessary" infrastructure spend that looks wasteful on a bill is actually redundancy that prevents exactly this scenario.
Watch the near misses too
Full outages get attention because they are undeniable and everyone notices at once. The costlier pattern over a year is often the partial degradation that never quite counts as an official outage, a system running slow enough that staff work around it, a checkout that fails intermittently for a fraction of customers, an integration that silently drops a small percentage of orders. None of these trigger the same alarm as a full outage, yet the cumulative cost across months can exceed a single dramatic incident. Apply the same hourly cost logic to degraded performance, not just total downtime, and you will usually find a second, quieter case for investment that was easy to overlook.
Know your number before you need it
Calculate your downtime cost once, this week, using your own real figures rather than industry averages that do not reflect your specific operation. Keep that number in mind the next time someone proposes cutting the hosting budget, skipping a staging environment, or delaying a system upgrade because things are working fine for now. Things working fine right up until the moment they do not is exactly the gap this number is meant to close.