Why use this calculator
Most downtime figures quoted inside organisations are wrong in the same two ways: they count revenue that was only delayed as though it vanished, and they ignore staff idle time entirely because nobody invoices for it. Separating the three components matters because they argue for different investments.
If your cost is dominated by staff idle time, the answer is a degraded mode that lets people keep working, or better internal communication so they switch to other tasks quickly. If it is dominated by revenue, the answer is failover and redundancy. If it is dominated by recovery labour, the answer is runbooks, automation and better observability so the fix takes an hour instead of a day.
Producing a single blended number hides all of that. This calculator also scales the incident to an annual exposure and to an implied availability figure, which is the form a finance team and a service level agreement both understand.
How to use it
- Enter the headcount actually blocked by the outage, taken from the affected system's active user list rather than total company headcount.
- Put in the average fully loaded hourly cost for those people, which payroll can supply per department as salary plus on-costs divided by productive hours.
- Set the share of idle time genuinely lost, using around 50 per cent for office roles that have a backlog to fall back on and 90 per cent for contact centre or production roles that simply stop.
- Enter revenue per hour for the affected service, calculated from its annual revenue divided by its actual trading hours.
- Set the share of lost revenue you recover later, which is high for business-to-business and subscription models and close to zero for impulse retail.
- Enter the outage duration as elapsed time from first customer impact to full restoration, and the share of operations affected, using 100 for a total outage.
- Add the total engineer hours spent responding and their fully loaded hourly cost, which is normally well above the average staff rate.
- Finally enter how many comparable incidents you have had in the last twelve months, from your incident register.
What each result means
- Lost staff productivity
- The value of paid time that produced nothing, after allowing for the work people switch to during an outage.
- Net revenue lost
- Trading genuinely destroyed rather than deferred. The note shows the gross figure so you can see how much was only delayed.
- Recovery labour
- Engineering and vendor effort during and after the incident, including data reconciliation and the post-incident review.
- Total cost of this outage
- The sum of the three direct components. Reputational and contractual costs sit on top and are deliberately not modelled.
- Cost per minute of outage
- The number to weigh against investments that buy back minutes, such as faster detection, automated failover and rehearsed runbooks.
- Cost per hour of outage
- The same figure in the unit most vendor proposals and availability service level agreements are written in.
- Revenue share of the total
- How much of the damage is trading rather than labour. A low share means resilience spending should target people and process, not just infrastructure.
- Annual exposure at this incident rate
- Cost per incident multiplied by your observed incident rate. This is the figure a resilience budget should be argued against.
- Outage hours to cut for 99.9% availability
- How many hours of unplanned outage a year you would need to remove to reach three nines, which allows under nine hours of downtime a year. The note values those hours at your lost productivity and revenue per hour.
- Annual downtime at this rate
- Total unplanned outage hours a year if incidents of this size keep happening at the rate you entered.
- Implied annual availability
- Your annual downtime expressed as an availability percentage, so it can be compared directly with a service level agreement target.
The formula
Lost productivity = staff blocked multiplied by fully loaded hourly cost multiplied by outage hours multiplied by the share of operations affected multiplied by the share of idle time genuinely lost
Gross revenue lost = revenue per hour multiplied by outage hours multiplied by the share affected
Net revenue lost = gross multiplied by one minus the share recovered later
Recovery labour = engineer hours multiplied by the engineering hourly cost
Total = productivity plus net revenue plus recovery labour
Cost per minute = total divided by outage hours times 60
Annual exposure = total multiplied by incidents per year
Implied availability = (8,760 minus annual outage hours) divided by 8,760, expressed as a percentage
How this number is used in practice
The figure most often quoted in downtime discussions is 5,600 US dollars a minute, attributed to Gartner. It is worth knowing that this number dates from a 2014 Gartner note, that Gartner themselves have cautioned against using it as a universal benchmark, and that it was an average across organisations of wildly different sizes.
Quoting a decade-old average as though it were your cost is the fastest way to lose credibility with a finance team. The Uptime Institute's annual outage analysis is a better reference point for how outage severity is distributed, and it consistently shows that the majority of outages cost relatively little while a small tail costs an enormous amount.
That distribution is the real argument for resilience spending: you are buying insurance against the tail, not shaving the average.
Separating the three components is what makes the number defensible. Direct revenue loss is the easiest to explain and the easiest to overstate, because a great deal of what looks lost is simply deferred. A business-to-business customer who cannot place an order at eleven in the morning places it at two in the afternoon, so counting the full gross figure inflates the case and invites a finance director to reject it.
Impulse retail and advertising-funded services are the opposite: a session not served is revenue that never returns. Recovery labour is the component teams forget entirely, yet it is often the largest item for internal systems, because it includes the engineers pulled off roadmap work, the overtime, the data reconciliation afterwards and the post-incident review.
Staff idle time is the component finance teams resist, since the wages were paid regardless, but the capacity was genuinely destroyed and the honest way to present it is with an explicit idle loss percentage rather than by assuming a full loss.
Reputational cost is real and is deliberately excluded here, because any attempt to put a figure on it is guesswork that undermines the credibility of the numbers that are solid. Present it qualitatively alongside the calculation: contractual service credits you will owe, customers who churn at renewal, sales cycles that stall while prospects ask about resilience, and regulatory attention in sectors with availability obligations.
Where you do have a hard number, such as service level agreement credits written into contracts, add it as a separate line rather than burying it inside an estimate. A board will accept a smaller number it can trust ahead of a larger one it cannot.
Worked examples
100 staff at $50/hr, $5,000/hr service revenue, a four hour outage affecting half of operations, 24 engineer hours of recovery
Total cost $16,280.00, or $67.83 a minute, and $65,120.00 a year at four incidents
500 staff at $75/hr, $50,000/hr revenue, a complete eight hour outage with 120 engineer hours of recovery
Total cost $614,400.00, or $1,280.00 a minute, and $3,686,400.00 a year at six incidents
A 20 person business losing an internal system for 90 minutes, twelve times a year
Total cost $1,695.00 per incident and $20,340.00 a year, dominated by staff idle time and recovery labour rather than lost revenue
When people use it
- Building the business case for redundancy, failover or a disaster recovery capability
- Deciding whether a vendor support tier or availability service level agreement is worth its premium
- Quantifying the payback on observability and alerting that shortens time to detection
- Putting a cost on an outage in a post-incident review so the follow-up actions get prioritised
- Comparing the cost of unplanned downtime with the cost of a planned maintenance window
Tips
- Split the number into productivity, revenue and labour before you present it. A blended figure invites scepticism and hides which investment actually helps.
- Never quote the Gartner 5,600 dollars a minute figure as your own. It dates from 2014, is an average across very different organisations, and will be challenged.
- Be conservative on revenue recovery for impulse purchases and generous for contracted or subscription revenue. Getting this wrong moves the total more than any other input.
- Log engineer hours during every incident, including the post-incident review. Teams consistently underestimate this by half when reconstructing it later.
- Track incident frequency in a register. The annual exposure figure is only as good as the incident rate you feed it.
- Measure elapsed customer impact time, not the time the fix took. The clock starts at first impact, not at the moment someone noticed.
- Convert the result into an availability percentage before talking to vendors, because that is the unit every service level agreement is written in.
What it assumes, and where it stops being accurate
- Assumes a constant rate of loss for the whole outage. Real outages often cause peak losses in the first hour, or during a trading peak, so a flat model understates a badly timed incident.
- Staff idle time is treated as a genuine loss at the percentage you set. Finance teams sometimes refuse to recognise any of it because the wages were paid anyway, so be prepared to present it separately.
- Revenue recovery is a single flat percentage. In practice recovery decays with outage length, since a customer who waits twenty minutes usually returns and one who waits a day often does not.
- Reputational damage, customer churn, contractual service credits and regulatory penalties are excluded entirely.
- Annual exposure assumes future incidents resemble the one you modelled and occur at the rate you entered. Incident severity is heavily skewed, so the mean is not the typical case.
- Not accurate for planned maintenance windows, partial degradations where the system stays usable but slow, or cascading failures that damage data and create work lasting weeks.
- Implied availability counts only unplanned downtime of this type against a 8,760 hour year and ignores every other cause of outage.
Terms used on this page
- Mean time to recovery
- Average elapsed time from an incident starting to normal service being restored.
- Availability
- The percentage of a period in which a service was usable. 99.9 per cent allows roughly 8.8 hours of downtime a year.
- Service level agreement
- A contractual availability or response commitment, usually with financial credits payable when it is missed.
- Failover
- Automatic switching to a standby system when the primary fails, which converts an outage into a brief interruption.
- Post-incident review
- A structured, blameless examination after an incident that identifies contributing causes and prioritises follow-up actions.
Questions people ask
- What does IT downtime cost on average?
- There is no useful average, because outage cost is skewed by a small number of very expensive incidents. Published surveys such as the Uptime Institute's annual outage analysis show most outages cost comparatively little while a minority cost millions. Model your own systems rather than adopting an industry mean.
- Should I count staff idle time as a real cost?
- Count the portion genuinely lost. Wages are paid either way, so the loss is the productive capacity destroyed, not the payroll. Office staff with a backlog may lose only half their idle time, while contact centre or production staff lose almost all of it. Set the percentage explicitly so the assumption is visible.
- Why does the calculator reduce revenue loss?
- Because a lot of it is deferred rather than destroyed. Business-to-business orders and subscription renewals usually land once service returns, so counting the gross figure overstates the case. Impulse retail and advertising-funded services are different, and for those you should set the recovery share close to zero.
- What is not included in this cost?
- Reputational damage, customer churn at renewal, contractual service level agreement credits, regulatory penalties in sectors with availability obligations, and the opportunity cost of engineering roadmap work displaced by the incident. Present those qualitatively alongside the number rather than guessing at a figure.
- How do I turn this into an availability target?
- The calculator shows implied annual availability from your outage hours and incident rate. Compare it against the tier you need: 99.9 per cent allows about 8.8 hours of downtime a year, 99.99 per cent allows about 53 minutes. Each additional nine typically costs several times the previous one.
- How do I use this in a post-incident review?
- Put the cost at the top of the review document alongside the timeline. Actions that reduce time to detection or time to recovery can then be ranked by the minutes they buy back multiplied by your cost per minute, which turns a list of well-meaning follow-ups into a prioritised set with a payback.
Use this with
IT Downtime Cost Calculator answers one part of the question. These pick up where it stops: Data Breach Cost Estimator, Cloud Cost Comparison Calculator, Employee Cost Calculator, Technical Debt Cost Calculator and Break-Even Calculator.
Where these figures come from
This calculation is jurisdiction-neutral arithmetic. No country-specific rules are applied.
- Uptime Institute. Annual outage analysis and severity distribution
- Google SRE Book. Availability targets, error budgets and incident response practice
- NIST Computer Security Resource Center. Contingency planning and incident handling guidance
- UK National Cyber Security Centre. Incident management and business continuity guidance
IT Downtime Cost Calculator produces an estimate for general information. It is not financial, tax, medical, legal or engineering advice. read the full disclaimer. Spotted a wrong number? Report it and it gets fixed. The form picks up this calculator and the inputs you used.