load-test-designerlisted

Most "load tests" hammer a single endpoint in a tight loop with no think-time, run from one laptop, and report an average response time that makes everyone feel good and predicts nothing. This skill designs a load test you can actually defend in a launch review. It builds a workload model from the real traffic mix, picks the test type that answers your actual question (Will we survive peak? Where do we break? Do we leak under sustained load? Can we absorb a surge?), writes thresholds tied to your SLOs *before* the run so the test has a pass/fail answer, and produces a runnable script plus a guide to reading the results by percentile and saturation point. ## When to use this skill - You have a launch, marketing event, sale, or migration coming and need numbers to prove the system survives expected peak. - You need to size infrastructure (instance count, DB connection pool, autoscaling thresholds) and want evidence, not a guess. - You want to find the breaking point — the concurrency or RPS at which latency or error rate falls off a cliff — before users do. - An existing load test reports a single average latency and nobody believes it represents real traffic. - You suspect a slow leak (memory, connections, file handles) that only appears after the system runs hot for an hour. ## Instructions 1. **Build a workload model from real traffic, not a single URL.** A load test that loops on `GET /health` measures your load balancer, not your system. Derive the endpoint mix from pr