Downtime Cost Calculator — What a Single Outage Really Costs
Plug in your revenue, how long you were down, and how much of the system was affected. Get a defensible dollar figure for a single outage — direct lost revenue plus recovery cost and reputation drag — so you can size what resilience is actually worth. Built by the team that ships resilient cloud infrastructure.
Your outage profile
Update any field — the cost of a single outage recalculates live.
Derived revenue per hour: $571/hr
100% means everything is down. Use a lower number if only part of the system is affected.
1.0 = no downstream damage. 1.25 means every $1 of lost revenue carries another $0.25 of churn, SLA credits, and lost trust.
Cost Of This Outage
$10,854
Exposed revenue ~$571/hr
Moderate exposure — worth hardening the obvious gaps
An outage at this level stings enough to justify health checks, automated alerting, and a tested rollback path. If you're on a single region or a single database instance with no failover, that's the first thing to fix — it's usually the difference between a brief degradation and a multi-hour incident.
What's driving your number
- •At $571/hr of exposed revenue, every hour of full downtime burns roughly that much before recovery and reputation costs.
- •A 1.25x reputation multiplier adds $571 for downstream churn, SLA credits, and lost trust.
- •$8,000 of incident-response and recovery cost (engineering hours, vendor escalation, overtime) is on top of lost revenue.
Want this as a shareable PDF for your leadership or incident-review meeting?
How to calculate the cost of downtime
The headline formula is simple: revenue per hour multiplied by the number of hours you were down, multiplied by the fraction of revenue actually affected. The hard part is getting those inputs honest. This calculator does the arithmetic live and then adds the two costs most back-of-the-envelope estimates forget — recovery cost and reputation drag — so the number you walk away with is one you can defend in an incident review or a budget conversation.
Start with revenue per hour. If your revenue accrues around the clock — most SaaS, e-commerce, and API businesses — divide annual revenue by 8,760 hours. If you only earn money during business hours, divide by roughly 2,080. The calculator supports both, and you can enter revenue per hour directly if you already track it. Then set how much of the system was affected: a full outage is 100%, but a degraded checkout while the rest of the app stayed up might be 30%. Architecture that isolates blast radius is precisely what keeps that number low.
Why direct revenue is only half the cost
Lost sales during the outage window are the obvious cost, but they are rarely the biggest one. Recovery cost — the engineering hours, the vendor escalation, the overtime, the war-room time that displaced planned work — is real money that lands the same week. And the reputation multiplier captures what shows up later: customers who quietly churn after a bad experience, SLA credits you owe under contract, and the trust you have to spend the next quarter re-earning. For an SLA-bound B2B product, that secondary cost can dwarf the revenue you lost in the moment.
Turning the number into a resilience budget
The point of this calculator is not to scare you — it is to right-size your spending. Resilience engineering has a clear cost-benefit logic: the right level of investment is the one that costs less than the outages it prevents, weighted by how often they happen. If a single outage costs you $5,000, multi-region failover is overkill and basic monitoring is plenty. If it costs $250,000, redundant infrastructure and rehearsed incident response usually pay for themselves the first time they catch a failure. The decision is fundamentally a build-versus-buy and invest-versus-accept tradeoff, and this number is the input that makes it rational.
The resilience ladder, cheapest first
In rough order of cost-effectiveness: uptime monitoring and alerting so you find out before your customers do; a tested rollback path so a bad deploy is a five-minute fix; multi-AZ deployments so one data-center hiccup is not an outage; database replicas with automated failover; graceful degradation so a non-critical dependency failing does not take the whole system down; and finally, for the highest-exposure systems, multi-region failover with a regularly rehearsed incident-response process. Each rung costs more than the last, and your downtime number tells you how far up the ladder it is worth climbing. This is the core of what our DevOps engineering practice delivers.
Assumptions this calculator makes
This estimates a single outage, not your annualized risk — multiply by your realistic incidents-per-year to get an annual figure. It treats revenue per hour as flat, so for businesses with sharp peaks (a flash sale, a market open), a peak-hour outage costs far more than this average implies. It does not model regulatory fines, contractual penalties beyond the reputation multiplier, or the morale cost of a brutal on-call week. Those are exactly the factors we tune to your situation on a call. If your system is showing its age and outages are getting frequent, that is often a sign it is time to weigh a rebuild against patching — our build-vs-buy guide for 2026 covers that decision in depth.
What you'll get
Related reading & tools
Cloud Infrastructure
Multi-AZ, failover, and the resilient foundation that keeps your downtime number small.
DevOps Engineering
Monitoring, rollback paths, and rehearsed incident response done right.
Penetration Test Cost Calculator
A breach is downtime with a compliance bill attached — size that risk too.
Build vs Buy Calculator
Weigh investing in resilience against accepting the risk, with a clear score.
FAQs
How is the cost of downtime calculated?
The core formula is revenue per hour x hours down x percentage of revenue affected, which gives direct lost revenue. We then add your recovery cost (engineering hours, vendor escalation, overtime) and apply a reputation multiplier to the lost-revenue portion to capture downstream churn, SLA credits, and lost trust. The result is a defensible total cost per incident.
Should I use 24/7 hours or business hours to derive revenue per hour?
Use 24/7 (8,760 hours/year) if your revenue accrues around the clock, like most SaaS, e-commerce, or API businesses. Use business hours (about 2,080 hours/year) if revenue only happens when your team or storefront is open. The calculator supports both, and you can also enter revenue per hour directly if you already track it.
What is the reputation multiplier and what number should I use?
It captures the damage beyond the immediate sale you lost: customers who churn after a bad outage, SLA credits you owe, and the trust you have to re-earn. A multiplier of 1.0 means no downstream damage; 1.25 means every dollar of lost revenue carries another 25 cents of secondary cost. Set it higher for SLA-bound B2B contracts and lower for low-stakes consumer traffic.
How do I reduce my downtime exposure?
In rough order of cost-effectiveness: uptime monitoring and alerting, a tested rollback path, multi-AZ deployments, database replicas with automated failover, graceful degradation, and finally multi-region failover with rehearsed incident response. The right level of investment is the one that costs less than the outages it prevents — which is exactly what this calculator helps you size.
Find your single points of failure before they find you
If this number is bigger than you're comfortable with, the next step is a 20-minute call. We'll map where your system breaks, what closing each gap is worth against your downtime cost, and the cheapest path to the uptime you actually need.
Or reach out directly: (770) 652-1282 · beltz@quantlabusa.dev