When a DDoS Attack Takes You Down: Protecting Business Continuity

Short answer: If you are already down, there are three things to do: hand the traffic to the edge, restore in order of business importance (login and payments first, then core APIs, then everything else), then remove the temporary rules and review. What decides how much it costs you, though, is the six things done before the attack — an attack surface inventory, alerting and on-call, pre-built layer 7 rules, origin lockdown, log retention, and a degradation plan for dependencies. In Q3 2026 Cloudflare autonomously mitigated 18.2 million network-layer DDoS attacks, about 8,226 per hour, with 96% of them ending in under 10 minutes and 98% below 1 Gbps. Those two numbers mean the bar for taking you down is lower than it looks, and a human response is usually slower than the attack itself.

How common DDoS really is: not if, but when

Cloudflare’s DDoS threat report for Q3 2026 puts numbers on this. Across its network that quarter it autonomously mitigated 18.2 million network-layer DDoS attacks and 14.4 trillion HTTP DDoS requests. That is roughly 8,226 network-layer attacks per hour, or one every 0.44 seconds. Mitigated traffic totalled 272.6 PB at the network layer and 95.1 PB at the HTTP layer.

The shape of those attacks matters more than the totals: 96% ended in under 10 minutes, and 98% stayed below 1 Gbps. Cloudflare attributes that short, small, high-frequency pattern to DDoS-for-hire “booter” services, aimed mainly at computer software, IT services and online gambling — businesses that depend on continuous availability. One gigabit per second is modest by internet standards, but in Cloudflare’s own words it is more than enough to overwhelm a single server or website.

Three things follow for a SaaS team selling abroad.

One: being small is not protection. Most attacks need very little bandwidth to succeed. A single unmitigated origin or a modest uplink is enough. Attackers pick targets by motive, not by how famous you are.

Two: a human response is usually slower than the attack. With 96% of attacks finishing inside ten minutes, the sequence of noticing an alert, assembling people, classifying and changing configuration often outlasts the attack itself. Cloudflare’s conclusion in the report is that most attacks end long before an analyst could see the alert. Mitigation therefore has one viable form: always on, and automatic.

Three: short bursts and hyper-volumetric attacks are two shapes, not two severity levels. The same quarter saw 251 attacks above 1 Tbps, and the longest Mirai-classified attack ran for 49.7 hours. You need cover for both.

What getting knocked offline actually costs

“Taken down” usually does not mean the site got slower. It means that for as long as the service is unavailable, the business is losing money in several places at once.

Revenue and conversion. Transactional businesses lose money by the minute. Subscription businesses lose something worse: users who were blocked during the outage do not come back later, they arrive as tickets, bad reviews and next month’s churn.

The cloud bill. When attack traffic reaches your origin or your autoscaling group, egress, request counts and instance hours all rise together. The invoice arrives after the incident, but the number was set during it. This is the most direct financial argument for absorbing traffic at the edge: keep it out of the part of the path you pay for by the byte.

Contracts and SLAs. Enterprise contracts usually carry availability commitments and service credits. A long outage triggers the credit, and then reappears at renewal and in the customer’s security questionnaire.

Acquisition and ad spend. While you are down, crawlers fail, ad budgets keep spending and landing page bounce rates spike. None of it shows up on an invoice, all of it shows up in next month’s acquisition cost.

People and opportunity cost. An incident without a runbook pulls engineering, operations and support in at once and stops the roadmap for a day or two. The expensive part is rarely the downtime; it is everyone dropping what they were doing.

Evidence and compliance. With no logs you cannot tell a customer whether their data was affected, and you cannot complete an incident notification where one is required. This cannot be backfilled afterwards.

One point worth making separately: only the first of these scales with the size of the attack. Everything else is decided by whether you prepared. The same attack costs a prepared team a few minutes of partial requests and an unprepared team several hours of downtime plus weeks of rebuilding trust.

Why mitigation belongs at the edge, and what Cloudflare adds

Once the frequency and the cost are clear, the next question is where to absorb the traffic.

The answer is as far from your origin as possible, which means the edge. The reasoning is simple: once attack traffic reaches your servers, your cloud account and your bandwidth, it is already being billed at your rates and consumed against your capacity ceiling. Edge mitigation is what keeps it out of the part of the path you pay for.

Cloudflare has three concrete advantages here.

One: capacity and location. Cloudflare’s network capacity is measured in the hundreds of terabits per second, across more than 330 cities. Attack traffic is absorbed close to its source instead of being funnelled down one of your origin links.

Two: on by default, and unmetered. Per the published availability table, standard unmetered L3-7 protection, HTTP DDoS attack protection and network-layer (L3/4) protection are all available on every Cloudflare plan. Whether the traffic can be absorbed has a default answer, and a large attack does not come with a large invoice.

Three: the speed of automation. The other side of the numbers above is that most attacks finish faster than a human can respond. Always-on automatic mitigation is the only form that works.

The boundary matters too. Automatic mitigation answers whether the traffic can be absorbed, not whether you still have decisions to make. What you still have to configure in advance includes overrides on the managed rulesets, layer 7 custom rules and rate limiting rules, alerting and on-call cover, origin lockdown, and log retention. Override counts are 1, 1, 1, 1 and 10 by plan. None of this is on by default, and it is what the rest of this article covers.

Six things to prepare before the attack

One: an attack surface inventory. Every externally resolvable hostname, subdomain, API endpoint, origin address and DNS provider, with the critical ones marked. What global teams usually miss are legacy subdomains, partner-integrated hostnames, and DNS-only records that resolve straight to origin infrastructure.

Two: alerting and on-call. All plans include alerts, and Enterprise with the Advanced DDoS Protection add-on gets advanced alerts with filtering. More important than the alert itself is who can decide: name the person who is allowed to authorise mitigation changes, before you need them.

Three: pre-built layer 7 rules. Custom rule counts are 5, 20, 100 and 1,000 by plan; rate limiting rules are 1, 2, 5 and 100, with the Enterprise count set by contract and application security required on it. Write and validate rules for login, payments, messaging and search endpoints now rather than authoring them mid-incident.

Four: origin lockdown. Protection at the edge is not the same as protection of the origin. Allow only Cloudflare’s published IP ranges, turn on Authenticated Origin Pulls, or move to Cloudflare Tunnel with outbound-only connectivity. Until one of those is in place, the direct-to-origin path is still open.

Five: log retention. Logpush caps jobs at 1,000 per account on Free, Pro and Business, with no account-level limit on Enterprise. Whichever tier you are on, get the pipeline running first: without logs there is no review afterwards and nothing to show customers or partners.

Six: a degradation plan for dependencies. Global SaaS products lean on third parties for payments, messaging, maps and identity. Those dependencies degrade during an attack too. A static fallback, feature flags and a queue in front of slow work are decided far better in advance.

The order of response, and who does what

0 to 10 minutes: confirm before you act. Three things in parallel: establish whether this is an attack or your own change, capacity limit or dependency failure; confirm that automatic mitigation is running; and scope the impact by endpoint, region and layer. The classic mistake in this band is blocking a batch of addresses before classification — that is where most false positives originate.

10 to 60 minutes: mitigate by endpoint tier. Order by business importance: login and accounts, payments and checkout, core APIs, then everything else. Prefer challenge to block: a challenge still lets real users through and can be withdrawn at any time, whereas a broad block is expensive to recover from. Record the creation time and rollback method for every temporary rule.

After: roll back and review. Remove temporary rules in order so nothing is left behind unnamed and unexplained. Record detection time, mitigation time, recovery time, false positives and customer-visible impact.

Three things not to do mid-incident. Do not block by country or by large address ranges before classifying the traffic. Do not switch proxied records to DNS-only during an incident — that publishes your origin address. Do not disable security controls for debugging without recording that you did.

Alongside the order of response, ownership has to be agreed in advance and written into the runbook.

One decision owner. A named person decides the severity level and whether mitigation changes are authorised. Multiple people issuing instructions at once is a common reason incidents drag on.

Network and security. Watch edge signals and rule hits, adjust overrides and thresholds, and log every change made.

Application and SRE. Watch origin error rates, queue depth and dependency health, and decide whether to degrade or shed load on the user side.

Support and external comms. Have a template ready to send immediately: acknowledge the impact, state when the next update will come, and say whether data was affected. Silence during an incident damages customer relationships more than the incident does.

Upstream. When to involve your cloud provider or Cloudflare depends on the layer affected and the response commitments in your contract. Write the escalation path into the runbook as named people and channels, not “we will work it out”.

One point specific to global businesses: customers sit in other time zones, so the attack may land in your night. On-call and authority have to span time zones, or the runbook has to state what anyone may do immediately under defined conditions.

What Enterprise adds to a runbook

The headline: basic mitigation is not tiered, what is tiered is how precisely you can prepare. Enterprise and the Advanced DDoS Protection add-on add the capabilities that make the runbook finer-grained and leave less for a human to decide mid-incident.

More room to override, and more to observe. The number of ruleset overrides, proactive false positive detection on new rules, and how wide adaptive coverage goes all decide how much judgement you can write into rules in advance.

Observe before you enforce. The Log action on WAF custom rules is an Enterprise capability. Running a new rule in logging mode to see who it catches before tightening it to block is what keeps false positives down.

More usable alerting and logs. Advanced alerts with filtering come with the Advanced DDoS Protection add-on, and Logpush has no account-level job limit on Enterprise (it is 1,000 per account on Free, Pro and Business).

Response commitments in the contract. Who you can reach, and through which escalation path, is written into the contract rather than improvised during the incident.

The table below mirrors Cloudflare’s published availability table so you can check each line during a technical review:

Capability	Free	Pro	Business	Enterprise	Enterprise + Advanced DDoS Protection
Standard unmetered L3-7 protection	Yes	Yes	Yes	Yes	Yes
HTTP DDoS attack protection	Yes	Yes	Yes	Yes	Yes
Managed rules customisation	Yes	Yes	Yes	Yes, with Log action	Yes
Ruleset overrides allowed	1	1	1	1	10
Proactive false positive detection	No	No	No	Yes	Yes
Adaptive DDoS protection	Error adaptive rules only	Error adaptive rules only	Error adaptive rules only	Error adaptive rules only	All adaptive rules
Profiling signals	Error rates only	Error rates only	Error rates and historical trends	Error rates and historical trends	plus client country, user agent, query string, ML scores
Alerts	Yes	Yes	Yes	Yes	Advanced alerts with filtering
Advanced TCP / DNS protection	Requires Magic Transit	Requires Magic Transit	Requires Magic Transit	Requires Magic Transit	Requires Magic Transit

Two notes: the table mirrors Cloudflare’s published availability table, so capabilities absent from it are simply not listed there rather than unavailable. Magic Transit is an enterprise-grade product for protecting your own address space or hybrid networks, and it is the prerequisite for Advanced TCP Protection and Advanced DNS Protection.

Put another way: whether the traffic can be absorbed is not the selection question. How much human judgement you still need during the incident is. And the time spent on human judgement is the time you are down.

What the Enterprise 100% SLA guarantees

This one comes up in almost every procurement review, and the commitment itself deserves a clear statement. Enterprise contracts carry an explicit availability commitment — the published wording: the service will serve customer content globally 100% of the time. What it guarantees is the availability of Cloudflare’s own service. Backing that commitment is the network described above: edge capacity past 500 Tbps across 330+ cities and 13,000+ interconnected networks. The largest attack on public record — 31.4 Tbps, with HTTP floods above 200 million requests per second — was mitigated automatically on it, with no customer disruption.

Two points are worth writing into the review notes:

• Mitigation is unmetered. Standard L3-7 protection runs automatically at any traffic scale, and no attack produces a traffic bill.
• The 100% commitment is contractual. It is not a marketing line; it is an SLA clause with defined remedies and response commitments.

The other half of business continuity — origin lockdown, dependency degradation, capacity and pre-built rules — is exactly what this runbook covers, and where we help.

The four failures we see most often, and how to rehearse them away

One: no alerting, or nobody on call. Learning about an attack from a customer hours in is both common and the worst version of this failure. The alerting and on-call chain must be testable without a real attack.

Two: mitigation rules were never pre-built. Rules written during an incident are unvalidated, more likely to cause false positives, and usually forgotten afterwards. Write them in peacetime, run them in an observing mode, and name them.

Three: the origin was never locked down. The edge looks healthy while the origin is down, and that failure mode is the hardest to diagnose. Allowing only Cloudflare ranges, enabling Authenticated Origin Pulls or moving to a tunnel is the only way to actually close that path.

Four: no log retention. Without logs there is no review, and no way to answer whether customer data was affected. Logs have to be running before the incident, not added afterwards.

One more that is often missed: downstream dependencies. Payment callbacks, messaging gateways and public object storage endpoints get hit during the same attack and sit outside your edge rules.

How to rehearse without a real attack. Take a hypothetical scenario — login traffic grows by an order of magnitude at 02:00 UTC — and walk through who is alerted, who decides, what changes, and what is said externally. The value is in exposing gaps in ownership, not in technical detail.

Observe before enforcing. Run new rules with a recoverable action and watch who they catch before tightening. Whether you can log without acting depends on the plan: the Log action on WAF custom rules is Enterprise-only.

Four things a rehearsal must cover. Whether alerts reach the on-call person; whether rule deployment and rollback are routine; whether the origin is genuinely unreachable from the public internet; and whether the external statement template is usable.

Four numbers for the review. Time to detect, time to mitigation, false positive rate, and customer-visible impact. Those matter more than how large the attack was, because the first three are things you can improve.

Rehearsals do not need to be frequent, but they need to happen: a tabletop exercise each quarter, and an attack surface refresh after every significant architecture change.

What a runbook cannot fix

• Origin capacity limits. An attack exposes a capacity problem early; scaling and architecture are separate work.
• Application-layer vulnerabilities and business logic. A slow endpoint can exhaust itself with no attacker involved, and that is invisible at the edge.
• Third-party dependency failure. When a dependency is down, edge rules do nothing; degradation and multi-vendor design are the answer.
• DNS and registrar issues. Query floods land on authoritative DNS, which needs its own design and a named owner in the runbook.
• Account and business abuse. Credential stuffing and promotion abuse are not traffic problems; their signals live in business data.
• The trade-off of concentrating ingress on one provider. That is a deliberate choice, and its costs and boundaries are covered in Can a CDN Protect Your Website from DDoS Attacks?.

FAQ

We are not a big target, so are we really at risk? Yes. In Cloudflare’s Q3 2026 data, 98% of network-layer attacks stayed below 1 Gbps, which is enough to overwhelm a single server or a modest uplink. DDoS-for-hire services pick targets by motive rather than by size, and a SaaS product that depends on continuous availability is exactly what they aim at.

Cloudflare mitigates DDoS automatically, so why write a runbook? Automatic protection answers whether the traffic can be absorbed. A runbook answers when the decisions get made. What actually costs money during an incident is the unvalidated rule, the unassessed configuration change and the unowned communication — not the absence of mitigation.

What actually decides how much an outage costs? Only the direct revenue loss scales with the size of the attack. The rest — the cloud bill, SLA credits, interrupted acquisition, people pulled off the roadmap, and the evidence you owe customers afterwards — is decided by whether you prepared. Same attack, very different bill.

What is the very first step during an attack? Confirm, then act. Distinguish an attack from your own change, capacity limit or dependency failure, confirm automatic mitigation is running, and scope the impact. Blocking by country or by large ranges before classification is the main source of false positives and second incidents.

What does Enterprise add over the free plan for incident response? Basic mitigation runs on both. Enterprise adds ruleset override capacity, proactive false positive detection on new rules, wider adaptive coverage and richer profiling signals. It also adds the Log action on WAF custom rules, so you can observe before blocking, along with advanced alerts with filtering and no account-level Logpush limit. Response commitments are written into the contract. Together these decide how precise the runbook can be.

Enterprise comes with a 100% uptime SLA. Does that mean we cannot be taken down? On mitigation capacity, the scale is the answer. Cloudflare’s edge network has passed 500 Tbps across 330+ cities, and the largest attack on public record — 31.4 Tbps, with HTTP floods above 200 million requests per second — hit Cloudflare’s network and was mitigated automatically with no customer disruption. Protection at this scale is not metered and is never billed by attack size. The 100% availability commitment is backed by a contractual SLA. What the SLA covers is the availability of Cloudflare’s own service; an origin hit directly, origin capacity and third-party dependencies sit outside it, and that half is what origin lockdown, degradation plans and a rehearsed runbook are for.

What happens after the attack? Remove temporary rules in order, record detection time, mitigation time, recovery time, false positives and customer-visible impact, then update the attack surface inventory and thresholds. Skip this and the next incident repeats the same problems.

Related reading

• How to Choose DDoS Protection for Global Businesses
• How to Mitigate HTTP Flood and Layer 7 Attacks
• How Attackers Find Your Origin IP Behind Cloudflare
• Cloudflare DDoS protection capabilities

If your plan is still “we will deal with it when it happens”, start with the attack surface inventory. Listing everything resolvable from the outside usually turns up a few things that should not be exposed — we can walk through it with you.