What £11,000 Per Minute Downtime Actually Looks Like Inside a Company

£11,000 per minute.

It's a number that's often cited in conversations about IT downtime. It lands with weight in board presentations. And then, in my experience, it quietly gets filed away under "things we hope don't apply to us."

I want to unpack that number. Because over 20 years in IT operations, I've watched companies consistently miscalculate the cost of their incidents - and the miscalculation almost always goes in the same direction. They count fewer than they should. And because they're counting less, they invest less in prevention than the problem actually warrants.


The calculation most companies make

When most people hear £11,000 per minute, they think about lost revenue. They calculate their average hourly revenue, divide by sixty, and decide the figure doesn't apply to their business. A company turning over £2 million a year isn't losing £11,000 every 60 seconds while its system is down.

That's true. But it's also not what the number means.

The cost of an IT incident is not just the revenue you didn't make while your systems were unavailable. That's the visible cost - the one that shows up immediately and clearly. The real cost is everything underneath it. And in my experience, the underneath is almost always larger than the visible part.


What I've watched adds up in the room

Let me walk through what I've actually seen accumulate during a major incident.

Staff time. Every engineer, developer, and support person pulled into the incident is off their normal work. A mid-level incident involving eight people for three hours is twenty-four hours of salary cost at minimum - before overtime, before the time to context-switch back, before the work that didn't get done that day. I've seen incidents where the people cost alone exceeded what the company thought the entire outage cost them.

Customer service volume. When a system goes down, and clients aren't proactively informed, they call. I've watched a two-hour outage with no communication generate enough inbound support volume to overwhelm a small customer service team for the rest of the working day. That cost never gets attributed to the incident. It should.

Management time. Your CTO, your Head of IT, possibly your CEO - all pulled into incident calls. Senior people at senior rates, doing coordination work that a well-structured process would have distributed to the right level automatically.

Client relationship damage. This is the one that doesn't show up in any spreadsheet until it's too late. A client who experienced a poor incident - not just the outage, but the silence, the delayed update, the confusion - starts quietly evaluating alternatives. You may not know about it for months. By the time you do, it's often already decided.

The follow-on cost. A poorly run incident produces a poor post-mortem, which produces no meaningful action, which means the same incident happens again. Every recurring incident carries the full cost of all the previous ones that weren't properly fixed.


Where the communication failure multiplies everything

Here is the part I want to be direct about, because it's the part most directly within your control.

The technical outage has a cost floor. However long it takes to fix the underlying problem, it takes that long. You can't always compress the technical resolution time - it depends on the complexity, the expertise available, and the infrastructure involved.

But the communication failure around the outage? That cost is almost entirely avoidable.

The spike in customer service calls when clients aren't proactively informed - avoidable. The CEO spending ninety minutes trying to get basic information because nobody is providing it - avoidable. The client who churned two months later because they felt ignored during the incident - avoidable. The repeat incident because the post-mortem was rushed and the actions were never followed through - avoidable.

I'm not saying you can prevent every outage. Nobody can. What I am saying is that the communication and coordination failure that runs alongside the outage is a separate problem - and one that, in my experience, accounts for a larger share of the total cost than most companies realise.


A more honest calculation

Instead of asking what downtime costs in the abstract, I'd encourage you to ask a different question: what did our last major incident actually cost, when you count everything?

Staff hours across every team involved. Management time. The customer service volume spike. Client relationship damage - even if it hasn't shown up as churn yet. Any follow-on incidents caused by the same root cause. The post-mortem was supposed to prevent recurrence, but it didn't.

Most companies have never done that calculation. Not because they're careless - because it requires connecting dots across departments that don't usually talk to each other about the same event.

When you connect those dots, the number is almost always larger than the visible outage cost. And the largest portion of it is almost always due to communication and coordination failures, not the technical problem itself.

That is what I call the Operational Chaos Tax. And unlike the technical outage, most of it is preventable.