Before the test
Start with permission and scope. Name the targets, allowed methods, rates, duration, test window, source ranges, stakeholders, provider contacts, and abort conditions. Share the plan with teams that may see alerts during the run.
Baseline normal behavior before traffic starts. Capture request latency, packet rate, bandwidth, CPU, memory, firewall drops, cache behavior, database health, and user-facing error rates.
- Written approval is stored and easy to find.
- Targets and ports are explicit.
- Provider or mitigation vendor is notified where needed.
- Rollback and stop contacts are available.
During the test
Increase traffic in controlled steps. Hold each level long enough to see whether the system stabilizes. Watch both infrastructure and user outcomes. If a stop condition is met, stop the test and preserve the timeline.
Keep notes as decisions happen. A clear timeline of alerts, mitigations, operator actions, and observed impact is often more useful than a single graph.
After the test
Write down what held, what failed, and what needs a fix. Assign owners and dates. Then rerun the same test profile after remediation so the team can prove the improvement.
A mature DDoS resilience program is a loop: plan, test, observe, fix, retest. The checklist is only useful when it leads to action.