1. Permissions and scope
Confirm ownership or written authorization covering IPs/hostnames, methods, intensity, and the testing window. Notify stakeholders (SRE, security, hosting) so alerts are expected. Review Acceptable Use and Terms for platform rules.
If authorization is missing, stop. Do not “borrow” a friend’s site or a random IP. That is the line between engineering and a booter misuse case described in Booters explained.
This section expands on 1. Permissions and scope for teams that need more than a one-line definition. Authorized stress testing is a measurement discipline: you apply controlled load to infrastructure you own, watch where it bends, and feed the findings into capacity and protection work.
Write down the hypothesis before you start. If you cannot explain what failure mode you expect to observe, you are not ready to choose a method or concurrency. Short iterative runs with clear abort criteria beat a single unmanaged peak.
Pair every run with observability on both the edge and the origin. Latency percentiles, error rates, connection-table pressure, WAF challenges, and recovery after stop are the signals that turn traffic into decisions.
Keep the work accountable. Use identifiable accounts, verified targets, and published rules such as Slammed.st Acceptable Use. Browse related material on the blog when you need adjacent topics.
2. Test plan
Write down the hypothesis (“checkout p95 stays under 800ms at N concurrents”), method (L4/L7), duration, ramp strategy, and abort criteria. Choose methods with L4 vs L7 guidance.
- Start small; increase only after baselines look healthy.
- Prefer shorter iterative runs over one long maxed blast.
- Reserve capacity on your plan so other work is not blocked.
This section expands on 2. Test plan for teams that need more than a one-line definition. Authorized stress testing is a measurement discipline: you apply controlled load to infrastructure you own, watch where it bends, and feed the findings into capacity and protection work.
Write down the hypothesis before you start. If you cannot explain what failure mode you expect to observe, you are not ready to choose a method or concurrency. Short iterative runs with clear abort criteria beat a single unmanaged peak.
Pair every run with observability on both the edge and the origin. Latency percentiles, error rates, connection-table pressure, WAF challenges, and recovery after stop are the signals that turn traffic into decisions.
Keep the work accountable. Use identifiable accounts, verified targets, and published rules such as Slammed.st Acceptable Use. Browse related material on the blog when you need adjacent topics.
3. Monitoring during the run
Watch edge and origin together: CDN/WAF dashboards, host CPU/RAM/NIC, database saturation, error budgets, and synthetic checks from outside the stressed path. Assign someone to hit the stop button if abort criteria trip.
This section expands on 3. Monitoring during the run for teams that need more than a one-line definition. Authorized stress testing is a measurement discipline: you apply controlled load to infrastructure you own, watch where it bends, and feed the findings into capacity and protection work.
Write down the hypothesis before you start. If you cannot explain what failure mode you expect to observe, you are not ready to choose a method or concurrency. Short iterative runs with clear abort criteria beat a single unmanaged peak.
Pair every run with observability on both the edge and the origin. Latency percentiles, error rates, connection-table pressure, WAF challenges, and recovery after stop are the signals that turn traffic into decisions.
Keep the work accountable. Use identifiable accounts, verified targets, and published rules such as Slammed.st Acceptable Use. Browse related material on the blog when you need adjacent topics.
4. After the test
Capture screenshots/exports, note the first failing component, file tickets, and re-test after fixes. Update runbooks. For defense-oriented follow-ups, use DDoS protection testing checklist.
Ready to execute on verified targets? Create a free Slammed.st account.
This section expands on 4. After the test for teams that need more than a one-line definition. Authorized stress testing is a measurement discipline: you apply controlled load to infrastructure you own, watch where it bends, and feed the findings into capacity and protection work.
Write down the hypothesis before you start. If you cannot explain what failure mode you expect to observe, you are not ready to choose a method or concurrency. Short iterative runs with clear abort criteria beat a single unmanaged peak.
Pair every run with observability on both the edge and the origin. Latency percentiles, error rates, connection-table pressure, WAF challenges, and recovery after stop are the signals that turn traffic into decisions.
Keep the work accountable. Use identifiable accounts, verified targets, and published rules such as Slammed.st Acceptable Use. Browse related material on the blog when you need adjacent topics.
Operations notes and common pitfalls
Teams often under-communicate. A stress window that is “known to engineering” but unknown to the NOC still creates chaos. Publish a short advisory: start/stop time, expected symptoms, escalation contact, and the exact targets in scope.
Another frequent mistake is changing too many variables at once — method, concurrency, cache rules, and WAF mode in a single run. Change one primary variable per iteration so causality stays clear when you write the post-test report.
Finally, budget time for recovery validation. Confirm that queues drain, autoscaling cools down, and error rates return to baseline after stop. If recovery is sticky, that finding is as important as the peak breaking point. See the authorized checklist and best practices for fuller process detail.
When you are ready to execute on verified infrastructure, create a Slammed.st account and size the plan to the hypothesis — not to a marketing Gbps number. Pricing context lives on the pricing page.