The bill is longer than "lost sales"
Ask what a DDoS attack costs and most people answer with revenue: the site was down for four hours, we normally take this much per hour, there is the number. That figure is real, but it is usually the smallest column in the table — and it is the only one that stops when the site comes back.
| Cost line | When it lands | Usually measured as |
|---|---|---|
| Lost gross profit | During the outage | Revenue per hour × gross margin |
| Engineering response | During, and for days after | Responders × fully loaded hourly rate |
| Infrastructure overage | On next month’s invoice | Autoscaling, egress, per-request platform fees |
| Support load | During and after | Extra tickets and calls × handling cost |
| Refunds, goodwill and SLA credits | Days to weeks after | Contractual credits, discretionary refunds |
| Wasted acquisition spend | During the outage | Ad budget delivered to a page that will not load |
| Churn and lost pipeline | Weeks to months after | Retention delta, abandoned trials and signups |
| Emergency mitigation fees | Immediately | Per-incident onboarding, "under attack" surcharges |
The last line is worth sitting with. Buying mitigation while you are already down is the most expensive moment to buy it, and it is the moment most people do.
Work out your hourly downtime number
Borrowed industry averages are useless for a decision about your budget — they average a bank and a blog together. Use your own figures:
Hourly cost = (hourly revenue × gross margin) + (responders × loaded hourly rate) + infrastructure overage per hour + support handling per hour
Two rules make the answer honest:
- Use a peak hour, not a daily average. Attackers do not fire at 04:00 on a Tuesday. Ransom campaigns and competitive attacks are timed for your busiest window, because that is where the leverage is.
- Use gross profit, not revenue, if you sell goods — you did not lose the cost of goods you never shipped. For SaaS and advertising businesses, the margin figure is high enough that revenue is a fair proxy.
A worked example for a store turning over €120,000 a month, attacked during an evening peak:
| Component | Working | Per hour |
|---|---|---|
| Lost gross profit | €670 peak-hour revenue × 45% margin | €300 |
| Engineering response | 3 people × €60 loaded rate | €180 |
| Infrastructure overage | Autoscaling and egress during the flood | €100 |
| Support load | 20 extra contacts × €6 handling | €120 |
| Hourly total | €700 |
Nothing in that table is exotic, and it already ignores everything that arrives later. Run it with your own numbers before reading on — the rest of this page is about what multiplies it.
Multiply by how attacks actually behave
A single clean four-hour outage is the friendliest possible shape, and it is not the usual one.
- Attacks arrive in waves. An attacker who gets a result stops, watches you recover, and starts again — often with a different technique. Each wave restarts your incident, your paging and your recovery tail.
- Degradation costs almost as much as an outage. A checkout that answers in eight seconds is technically up and converts like a site that is down. If you only count hard downtime you will under-count most application-layer attacks.
- Recovery is not instantaneous. Caches are cold, queues are backed up, and the first minutes after mitigation are frequently the slowest ones your real customers experience.
- Success invites repetition. A target that went down once is a target with a proven method. This is the mechanism behind ransom DDoS: the first attack is a demonstration, and it is priced as marketing.
The costs that arrive after the site is back
Customers who leave quietly. Nobody sends an email to say they gave up at the payment step. The loss shows up as a dent in a cohort weeks later, which is exactly why it never gets attributed to the incident.
Search visibility. If crawlers meet errors or timeouts for hours, that is what gets recorded about your availability. It is rarely catastrophic, and it is rarely free.
Acquisition spend delivered into a wall. Paid campaigns keep spending through an outage unless somebody remembers to pause them, which means you pay full price for clicks that land on a broken page.
The paperwork. Post-incident review, customer notifications, questions from your board, and — if you carry cyber insurance — an evidence pack. Per-request logs and analytics turn that from a week of archaeology into an export, and they are the difference between "we think we were attacked" and a defensible account of what hit you and what stopped it.
The asymmetry is the whole argument
Attack capacity is a commodity. Botnet time is rented by the hour on underground markets for the price of a couple of coffees, and the attacker’s cost does not rise with the value of the target. Yours does: the bigger and busier your business, the more each hour costs you.
That asymmetry is why "we are too small to be attacked" is backwards. The attack is cheap regardless of who you are — so the deciding factor is not whether you are worth attacking, but whether attacking you is easy.
What protection costs, and the traps in the pricing
Mitigation is priced in tens of euros a month. That comparison is only fair, though, if the pricing does not have a trapdoor in it. Five questions to put to any provider, yours included:
- Is attack traffic metered against my quota? If it is, being attacked produces an invoice on top of the downtime — a second bill for the same incident.
- Is there a per-incident or emergency onboarding fee? Prices that appear when you are already down are not prices you get to negotiate.
- Does mitigation start automatically, or after a support ticket? Every minute between "attack starts" and "filtering starts" is billed at your hourly downtime rate. This is the practical case for always-on filtering, covered in what is DDoS mitigation.
- What do false positives cost me? A defense that answers every flood by showing a CAPTCHA to real customers is converting an availability problem into a conversion problem.
- Can I prove what was blocked? You will need that for customers, insurers and your own post-incident review.
Itnetic answers the first one plainly: attack traffic is scrubbed and never metered against your bandwidth quota, so an attack does not turn into a bandwidth bill. Filtering is always-on rather than something you switch on mid-incident, there are no per-attack fees, and every blocked request is logged. The Starter plan is free, Hobby is €10 a month and Pro €29 — see pricing — and going live is two DNS records and about five minutes.
Put that next to the worked example above. A single six-hour incident at €700 an hour costs roughly €4,200, which is more than a decade of the plan that would have been filtering it. That is the arithmetic; the cost of a DDoS attack is high mostly because the alternative is so cheap.
Already under attack while reading this? Skip the budgeting and go to how to stop a DDoS attack.