DDoS attacks are survived or suffered on organizational grounds, not technical ones. The edge capacity of any major CDN dwarfs almost any attack; what fails is the human layer — nobody knows who can flip which switch, whether the provider hotline needs a contract number, or what normal traffic looked like an hour ago. All of that is fixable on a quiet Tuesday, which is when this runbook gets written.
Why runbooks beat reflexes
Mid-attack, three things are simultaneously true: the site is degrading, leadership wants answers, and every action carries risk — tighten the wrong rule and you finish the attacker’s job on their behalf. Decisions made under that pressure, by whoever happens to be on call, are reliably worse than decisions made in advance. The runbook’s purpose is to move every possible decision to before the attack: what we will do, in what order, triggered by what evidence, executed by whom. What remains during the incident is recognition and execution — tasks that survive adrenaline.
Know your protection before you need it
Page one is an honest inventory of what stands between you and an attack. Which DDoS protection is actually active on your plan — always-on mitigation, or on-demand scrubbing that must be triggered? What does the contract promise as time-to-mitigate, and what does escalation require: a phone number, a ticket priority, a customer ID that should be printed on this page? Is the WAF in front of everything or only some hostnames; do rate limits exist on login and search; is the origin reachable directly (if so, fix that first — see protecting your origin, because a discoverable origin turns every edge defence into scenery)? Attack types map to defences unevenly — volumetric floods die at the edge network, protocol attacks at the terminating layer, and application-layer floods of expensive requests are the ones your own configuration must handle — our attack taxonomy maps which is which.
Pre-approved actions: the switch list
The heart of the runbook is a short, ordered list of actions that need no meeting: each with its trigger, its command or dashboard path, its blast radius, and its rollback. Typical ladder: raise cache aggressiveness (serve stale, extend TTLs) so the origin sees less of everything; tighten the rate limits you already run from normal to defensive thresholds; enable the platform’s under-attack or high-security mode, accepting the challenge friction it adds for real users; restrict or challenge traffic from regions where you do no business, accepting the collateral; and, last, static-page mode for the most expensive paths. Write down what you will not do as well — no ad-hoc firewall rules against single IPs (modern attacks rotate sources faster than you can type), no DNS changes mid-incident unless the plan explicitly includes them. Pre-approval means the on-call engineer executes the ladder alone, at 3 a.m., without waking a director.
Baselines, detection and the decision tree
You cannot recognize abnormal without normal written down: requests per second by hostname at peak and trough, origin load, typical cache-hit ratio, top paths. Snapshot these quarterly into the runbook. Detection should not depend on the attack being obvious — alert on origin saturation, error-rate jumps, and edge-reported mitigation events, and remember an application-layer attack can look like a modest traffic rise that happens to hit your slowest endpoints. Then the first decision in the tree: is this an attack, a legitimate spike, or a self-inflicted incident? A sale, a viral link and a deploy gone wrong all resemble attacks at first glance, and the defensive ladder applied to real customers is its own outage — the overlap with spike preparation is deliberate, because the first three rungs are identical and safe either way.
Communication, evidence and the drill
Write the comms templates now: an internal first notice (what we see, what we have done, next update time), a status-page entry that says “degraded, mitigating” honestly, and a support macro. During the incident, capture evidence as you go — timestamps, screenshots of provider dashboards, mitigation events, request samples — both for the post-incident review and because SLA credits and any upstream claims will demand it; pricing and credit structures across the protection market are covered in our DDoS protection pricing piece. Finally, drill it: once or twice a year, walk the on-call rotation through a tabletop scenario against the runbook, and fix what confused people. A runbook nobody has rehearsed is a document; a rehearsed one is a capability.