Short probes vs sustained holds
Short probes (30–120s) are for finding the first cliff quickly. Sustained holds (several minutes) are for autoscaling, cache warmup, memory leaks, and “does it stay broken.” Most teams need both — never only a single max-length blast.
Plan max duration is a ceiling, not a target. Abort when you have the signal. Process: authorized checklist.
Short probes and sustained holds answer different questions, and most authorized programs need both. A 30–120 second probe is ideal for finding the first cliff quickly: connection-table exhaustion, immediate 5xx, or a WAF rule that trips at modest concurrency. A multi-minute hold is for autoscaling reaction, cache warmup, memory growth, queue stickiness, and “does it stay broken after the spike.” Running only a single max-length blast often wastes the early signal and fatigues the people watching dashboards until nobody can narrate what failed first. Plan max duration is a ceiling, not a target — abort when the hypothesis is answered, then schedule a follow-up if a different question remains on systems you own.
Write the intended length into the runbook beside the method and abort rule so on-call does not invent timing under pressure. Process detail is in authorized stress test checklist and best practices. Layer still matters: short L4 smokes for edge questions, longer L7 plateaus for API and website realism — see L4 vs L7. Keep the entire window inside authorized load testing, and size the ceiling from pricing so Trial or paid max time matches the design instead of forcing an accidental truncation mid-hold that invalidates the plateau. If stakeholders demand a longer run without a new hypothesis, push back: duration without a question is calendar spend, not engineering signal. Record why you chose each duration in the ticket; that note becomes the template for the next release rehearsal.
Budget cool-down time
After stop, watch 5–15 minutes. Sticky queues, slow scale-in, and elevated error rates after traffic ends are real findings. Skipping cool-down is one of the most common mistakes.
Budget cool-down time as deliberately as ramp time. After you stop generating load, watch five to fifteen minutes for sticky queues, slow scale-in, elevated error rates, connection leaks, and cache stampedes that appear only when traffic ends. Skipping cool-down is one of the most common mistakes in otherwise careful rehearsals: the send phase looked fine, the recovery did not, and nobody was still looking at the boards. Cool-down findings are real capacity defects — treat them as tickets with the same seriousness as mid-run cliffs, and attach metric links while context is fresh enough to explain to leadership.
Assign an owner to call the end of cool-down and capture screenshots or metric links before the room disperses into other meetings. Guidance lives in stress testing best practices and the operational checklist at how to run an authorized stress test. For website peaks, pair with Black Friday playbook; for APIs, use API before launch. Stay within Acceptable Use and verified targets; cool-down is observation on your systems, not an excuse to extend unauthorized traffic. Document recovery time-to-green so the next release has a baseline instead of folklore about “it usually comes back.” Include cool-down ownership in the same paging rotation as the send phase so recovery defects do not become orphaned lore. If recovery is slower than the send phase, that asymmetry belongs in the executive summary, not only in a buried dashboard screenshot.
Practical defaults
- Edge/pipe L4 smoke: 30–60s steps
- API/homepage L7 plateau: 2–5 minutes per step
- Peak rehearsal: multiple steps totaling under your attention window for live monitoring
On Slammed.st, Trial caps are intentionally short; paid plans extend max time for longer holds. See plans.
Practical defaults help teams start without inventing timing from scratch every release. Edge or pipe L4 smokes often work in 30–60 second steps. API or homepage L7 plateaus often need two to five minutes per step so autoscaling and caches can move. Peak rehearsals should total a duration your humans can actually monitor live — attention is part of the instrument, and a six-hour unsupervised blast is rarely better science. Multiple shorter windows with clear hypotheses beat one exhausted marathon that nobody can narrate afterward. Always include cool-down in the calendar invite, not as an afterthought whispered after stop when people are already leaving.
On Slammed.st, Trial caps are intentionally short for workflow learning; paid plans extend max time for longer holds — compare cards on pricing and start at register. Read operator notes in docs and governance in authorized load testing. Related sizing topics include pricing explained and concurrents vs RPS. Choose duration to produce evidence on infrastructure you own; stop when the signal is enough, then re-test after remediation instead of extending a noisy run that no longer answers the original question. Revise defaults after two or three windows; your stack’s autoscale lag and cache TTLs are better teachers than generic minute ranges. Align plan max time with the longest plateau you actually intend to watch live — unused ceiling is fine; unwatched ceiling is waste.