When a DDoS attack lands at 2am, the last thing you want is an on-call engineer improvising. You want them following a runbook — a pre-agreed sequence that turns a chaotic hour into a series of checkboxes. The template below is organised around the first 60 minutes, the window where the difference between a documented process and a panicked scramble is most visible. It assumes you are behind reverse-proxy protection; adapt the specifics to your own tooling.
Minutes 0–5: Detect and Confirm
- Check monitoring: is this a brief spike or a sustained attack?
- Identify the vector: volumetric (bandwidth exhaustion) or Layer 7 (request exhaustion)? They need different responses.
- Check your protection dashboard: is mitigation already active, and what attack type is shown?
- Page the incident lead — treat it as a P1 until proven otherwise.
Minutes 5–15: Contain
- Verify DNS still points at your proxy (run dig on your domain from an external network).
- Enable or tighten emergency rate-limiting rules from the dashboard if not already in effect.
- If the attack is clearly concentrated in regions you don't serve, apply a temporary geo restriction — carefully, so you don't block real users.
- Turn on emergency caching to serve cached pages and take load off the origin.
Minutes 15–45: Communicate
- Post an internal incident update: what's happening, current impact, who owns it.
- Update your public status page — 'investigating elevated error rates' beats silence.
- Notify customer success if enterprise or SLA-bound customers are affected.
- Loop in leadership if SLA thresholds are being breached or the incident is prolonged.
Communication is part of the response
Half the damage of an outage is uncertainty. A status page updated every 15 minutes — even to say 'still investigating' — preserves trust that silence destroys. Assign someone to communication so the responders can focus on the fix.
Minutes 45–60: Resolve and Document
- Confirm the attack is fully mitigated and legitimate traffic is flowing normally.
- Start the incident document while it's fresh: timeline, attack profile, actions taken.
- Schedule the post-mortem within 48 hours.
- Review whether any rate-limit or rule tuning should become permanent.
Where Akarguard Fits the Runbook
A good runbook assumes protection is already in place before the incident, and Akarguard is designed to make most of these steps automatic rather than manual. Because it sits in the traffic path via DNS, mitigation is already active when the attack begins; automatic escalation raises protection without waiting for step one; the dashboard shows the live attack type and lets you tighten rate limits, apply geo rules or enable caching in seconds; and each incident produces a report that seeds your documentation and post-mortem. The runbook still matters — communication and decisions are yours — but the containment steps shrink from frantic configuration to confirmation.