When a monitoring vendor publishes a downtime-cost figure, it usually lands at some implausibly round number. £5,000 an hour for an SME, £1 million an hour for a bank. The numbers are designed to concentrate your attention on the sales slide behind them. What they almost never do is show the workings. This article does the workings. We walk through the four ways downtime actually costs a UK business money, we apply that framework to two worked examples, and we show where monitoring genuinely reduces the figure — and where it does not. If you are new to the monitoring conversation altogether, start with our plain-English introduction to Uptime Kuma and come back to this article afterwards.
Why the headline numbers keep being wrong
Industry benchmarks — Gartner, ITIC, Forrester — publish hourly downtime-cost figures every year. They are genuinely useful for Fortune 500 boardroom presentations. They are almost useless for a UK business with 30 employees. There are three reasons.
First, survey averages smooth over the things that matter most about your business. Whether you sell physical goods or subscriptions, whether your traffic is peaky or flat, whether your customers can work around an outage or not — all of that is lost in an average.
Second, the numbers aggregate costs that are not directly comparable. A direct revenue loss is a real pound that has left the business. A "productivity loss" is an estimate based on headcount salaries and an assumption about how completely idle staff are during the outage. A "brand damage" figure is, in honesty, mostly educated guessing. Lumping all three together produces a single big scary number that cannot be defended against a finance director.
Third, the published numbers are systematically pessimistic. Vendors publish them because downtime is their problem domain; the higher the number, the easier their product is to sell. That does not make the numbers wrong, but it does mean you should calculate your own rather than adopt an industry average wholesale.
The four cost layers of downtime
A more honest framework separates the cost of downtime into four layers. Each has a different degree of certainty, and each is worth quantifying separately.
| Layer | What it is | Certainty |
|---|---|---|
| 1. Direct revenue loss | Transactions that would have happened but did not | High — measurable |
| 2. Productivity loss | Staff time spent idle, on the incident, or on recovery | Medium — estimable |
| 3. Customer churn & CAC | Customers who leave, or who cost more to acquire after an outage | Lower — measurable over months |
| 4. Brand & reputation | Longer-term damage to market position, hiring, partnerships | Lowest — largely qualitative |
When you hear a big single-figure downtime-cost estimate, it is almost always adding these four layers together without labelling them. The layers are worth keeping separate because they respond to different interventions — and because a finance director will find a £3,000 direct revenue loss easier to act on than a £15,000 blended figure where most of the mass is qualitative.
Layer 1: Direct revenue loss
This is the layer most people think of first. If customers cannot transact, you do not earn the money they were about to spend. For a UK e-commerce business this layer is straightforward arithmetic: last week's daily revenue, divided by the trading hours, gives you a defensible £-per-hour figure. For a subscription business this layer is smaller than people expect — the direct loss during an outage is limited to new sign-ups that did not happen, not the recurring revenue of existing subscribers, unless your contracts include uptime-linked credits (more on that below).
A worked minimum: a UK Shopify store turning over £10,000 per day, open 12 hours, loses roughly £830 per hour of hard downtime before we count anything else. That figure rises sharply if the outage coincides with a peak trading hour, a promotional campaign or seasonal demand. Friday afternoon at 4pm in the run-up to Christmas is not the same as Tuesday lunchtime in July.
A common mistake is to assume all missed transactions are lost revenue. In practice, some customers come back an hour or a day later. The realistic recovery rate varies by sector — e-commerce sees maybe 40-60% recovery for planned shoppers; impulse-driven traffic (news sites, travel bookings) recovers much less. When you calculate your layer 1 figure, multiply gross missed revenue by a recovery-loss factor between 0.4 and 0.8 to avoid overstating the damage.
Layer 2: Productivity loss
When your service is down, other things stop too. Internal tools that depend on the service stop being useful, so colleagues sit idle or work slower. The engineering team is pulled into the incident response, abandoning whatever they were doing before. Customer-support colleagues field a wave of "it is not working" tickets. Everyone is busy, and almost none of that busyness produces new value.
The usual rough measure is headcount affected × hourly loaded cost × hours of impact × a reduction factor. The reduction factor acknowledges that people are not 100% idle during an outage — they can do other things, just less efficiently. A sensible default is 0.5 for direct blast radius (people whose work actually depends on the failing service) and 0.2 for wider knock-on (people whose work slows down because of the commotion).
For a UK team of 20 people with a £35/hour average loaded cost, a 2-hour outage that touches half the team directly costs 10 × £35 × 2 × 0.5 = £350 in direct productivity loss, plus around £140 in knock-on. Not ruinous, but repeated across several incidents per quarter, it adds up.
Layer 3: Customer churn and acquisition cost
Customer churn is slower to materialise and harder to attribute, but it is real. A single severe outage rarely causes mass churn; a pattern of outages, or a single very visible one, quantifiably does. The measurable proxies are (a) subscription cancellations in the weeks after an outage, compared with a baseline month, and (b) spike in support ticket volume and tone, which flags dissatisfaction that may not convert to immediate cancellation but does shape renewal conversations.
For UK B2B SaaS specifically, the churn cost is often amplified by the customer acquisition cost (CAC) you will have to spend to replace the lost customers. If your blended CAC is £800 and an outage drives a 2% incremental churn on a 500-customer base, that is 10 customers × £800 = £8,000 of additional CAC needed to restore the baseline — before you even think about the revenue lost.
There is a good case for treating this layer as the business case for investing in monitoring. Layer 1 losses are painful but one-off; layer 3 losses compound because the customers you lose could have generated revenue for years.
Layer 4: Brand and reputation damage
This is the hardest layer to quantify, and the one where marketing slide decks over-reach most aggressively. Long-term brand damage from outages is real, but it is notoriously hard to isolate from all the other things that affect brand. The honest approach is to track it qualitatively rather than pretending to a false precision.
What genuinely matters for UK businesses in this layer:
- Public procurement. Local government and NHS RFPs routinely ask for documented uptime figures. A visible outage during the procurement window is disproportionately damaging. Monitoring that records historical uptime gives you defensible numbers to submit.
- B2B reference customers. Large UK customers sometimes agree to be named as reference accounts. Those agreements wobble after high-profile outages.
- Hiring. Engineering candidates read status pages. A status page full of angry red incidents is a quiet drag on hiring pipelines.
- Partnerships. Integration partners track availability of the services they depend on. Repeated outages trigger escalations you did not want to have.
Treat layer 4 as a qualitative multiplier on the quantitative layers rather than a number in its own right. "Outages are painful at X pounds per hour, and they make several other parts of the business noticeably harder" is more defensible than pretending to a precise brand-damage figure.
Worked example — a UK e-commerce shop
Scenario: a UK-facing Shopify store selling home-and-garden products. Annual revenue £3.5M, peak month December. Team of 18 including 4 engineers. Average daily revenue £9,500 (higher in Q4). A 3-hour outage on a Wednesday afternoon in October.
| Layer | Calculation | Pounds |
|---|---|---|
| 1. Revenue | £9,500 / 12h × 3h × 0.6 recovery-loss factor | £1,425 |
| 2. Productivity (direct) | 4 engineers × £45/h × 3h × 1.0 (in the war room) | £540 |
| 2. Productivity (knock-on) | 10 other staff × £30/h × 3h × 0.2 | £180 |
| 3. Churn & CAC | negligible for one-off retail transaction | £0 |
| 4. Brand | qualitative — noted on post-incident review | qualitative |
| Total quantifiable | £2,145 |
The headline number for this shop is roughly £715 per hour of downtime, which is a long way below the "£5,000 an hour for SMEs" figure that you will see in vendor slides. That is normal — vendor averages are skewed upwards by very large deals.
What changes this number dramatically is timing. The same 3-hour outage on Black Friday would easily be 4-6 times as expensive, because the recovery-loss factor worsens (shoppers spread their spend across competitors when one site is down) and the knock-on productivity cost spikes as every colleague is pulled into incident response.
Worked example — a UK B2B SaaS
Scenario: a UK-hosted B2B SaaS with 450 customers on subscriptions averaging £250/month. Team of 28 including 12 engineers. Average blended CAC £1,100. A 4-hour outage during UK business hours.
| Layer | Calculation | Pounds |
|---|---|---|
| 1. Revenue (new signups) | 2 signups deferred × £250 MRR × 12 × 0.5 conversion loss | £3,000 |
| 2. Productivity (direct) | 12 engineers × £55/h × 4h × 1.0 | £2,640 |
| 2. Productivity (knock-on) | 16 other staff × £40/h × 4h × 0.2 | £512 |
| 3. Churn | 2% incremental churn × 450 × £3k LTV | £27,000 |
| 3. CAC replacement | 9 replacement customers × £1,100 CAC | £9,900 |
| 4. Brand / procurement | qualitative — mentioned in two live RFPs | qualitative |
| Total quantifiable | £43,052 |
For the SaaS, the dominant cost is layers 3 and 4, not layer 1. The direct revenue impact is tiny — existing customers continue paying their monthly subscription regardless of a 4-hour outage. The real damage is churn, retained-trust erosion and the procurement pipeline disruption. This is the pattern that surprises founders most: the reason uptime matters in SaaS is not revenue-during-outage but cohort-behaviour-after-outage.
UK-specific factors that amplify the bill
Several UK-specific factors make downtime more expensive than a global average would suggest.
Public sector SLAs. If you sell to local councils, NHS trusts or central government, your contracts typically include SLA clauses with hard uptime percentages and service credits for breach. An outage that drags you below the contractual floor can cost you tens of per-cent of monthly invoiced revenue, not through lost sales but through automatic credits applied to invoices.
UK GDPR notification timelines. If an outage turns out to be a security incident rather than a simple infrastructure failure, the UK GDPR's 72-hour notification window adds legal and communications workload — inside and outside lawyers, ICO notifications, customer communications. That is not a line on a monitoring-tool ROI calculator, but it is a real cost that prolonged uncertainty during an outage amplifies.
Press and social amplification. UK tech media picks up outages at smaller companies than the US equivalent threshold. A 4-hour outage at a 10M-ARR UK SaaS is routinely mentioned in trade press; the same outage at a 100M-ARR US company might not be.
Customer expectations. UK B2B customers tend to be polite about outages but long memories. "We had an outage that Tuesday" can surface in a renewal negotiation six months later.
How monitoring reduces the cost
Monitoring does not prevent outages. Engineering does that. What monitoring does is shorten the time between the outage starting and the outage being noticed. That interval — mean time to detect, or MTTD — is the bit that monitoring compresses. A reliable monitoring setup reduces MTTD from "however long until a customer complains" to "however long until the first monitor interval detects the failure" — typically under a minute.
Shorter MTTD shortens every layer of the cost. Revenue loss is directly proportional to outage duration. Productivity loss ditto. Churn and brand damage are magnified by outages that last long enough to be noticed externally; shortening duration below the threshold where external users are affected materially changes the churn picture.
The leverage is largest for businesses where the current MTTD is "when the first customer rings" — which is most small UK businesses. Moving from a 30-minute detect-time to a 60-second detect-time roughly halves the effective duration of most outages and, therefore, roughly halves their cost.
Tools matter less than coverage. Uptime Kuma configured well is better than a paid tool configured badly. Our HTTP(s) monitoring guide covers the baseline setup. The SMTP notifications guide is the natural follow-on, because a monitor that detects a failure but routes the alert to a dormant inbox is worth nothing.
The managed Uptime Kuma offer on smartxhosting.uk gives you a fresh Uptime Kuma instance on UK infrastructure. The instance itself runs on separate infrastructure from whatever you are monitoring, which is the single most important design choice for ensuring your monitor does not vanish during the incident it is supposed to detect. You log in, create the admin account and configure your first monitors the same way you would on any self-hosted instance.
How to calculate your own number
A workable homespun calculation takes roughly 30 minutes. Put the following on a single page:
- Average hourly revenue during business hours (annual revenue ÷ trading hours)
- Realistic recovery-loss factor (0.4 for impulse, 0.7 for routine, 0.8 for captive)
- Loaded hourly cost of the team likely to be pulled into an outage
- Typical incident duration today (based on the last 3-5 outages)
- Projected incident duration with monitoring in place (usually 50-70% lower)
Multiply out and you have a first-pass annual cost of downtime, plus a projected saving from adding monitoring. That number is usable in a business case. It is not perfect, but it is much better than adopting a vendor-supplied industry average that bears no relationship to your business.
What to invest in first
Three levels, in order.
First: monitoring that you trust. The baseline. No monitoring, or monitoring nobody looks at, is functionally equivalent to no monitoring at all. The cost is modest and the cost-of-downtime payoff is immediate. If you are weighing specific tools, our Uptime Kuma vs Uptime Robot comparison walks through the decision for UK buyers.
Second: separation of your monitoring instance from what it monitors. A self-hosted Uptime Kuma on the same VPS as your site is not real monitoring — when the VPS fails, both go dark and nobody gets alerted. Managed hosting on smartxhosting.uk solves this automatically; self-hosters need to choose an independent platform.
Third: a status page that actually gets used. An internal status page is useful. A public status page communicated to customers is more useful. An external probe that watches your monitoring instance and pages somebody if it falls over is the stretch goal for anyone who takes downtime seriously.
Summary
The cost of downtime is real, measurable and almost always miscounted. Vendor averages are too high for most UK SMEs and too low for the very largest ones. The honest approach is to separate the four cost layers — revenue, productivity, churn, brand — quantify the first three, treat the fourth qualitatively, and apply the result to the specific shape of your business. Monitoring is the cheapest and fastest-payoff investment for reducing the total bill, because it compresses detection time, which compresses every other cost line.