What this prompt does
This prompt builds a full API load-testing suite for [api_description] using [load_test_tool]. Instead of one generic "hammer the endpoint" script, it asks for five distinct test types: a smoke test, a load test at [concurrent_users] users for [duration], a stress test that ramps to the breaking point, a spike test that surges to [spike_users], and a soak test that sustains load for [soak_duration]. It layers in realistic scenarios with think time, an authentication flow, custom metrics ([custom_metrics]), performance budgets (p95 < [p95_target]ms, error rate < [error_target]%), and CI integration with pass/fail thresholds.
The structure works because each test type answers a different question. Smoke confirms the script works, load confirms normal traffic is fine, stress finds where it breaks, spike checks sudden surges, and soak exposes leaks that only show over hours. Wiring the budgets into CI is what turns a one-off benchmark into a regression guard, so performance can't quietly erode release to release.
When to use it
- You're about to tell a stakeholder an API is "ready" and want evidence under realistic load.
- You suspect a memory or connection leak that only appears under sustained traffic.
- You're sizing infrastructure and need to know where the API actually breaks.
- You're preparing for a launch, sale, or campaign with a predictable traffic spike.
- You want CI to fail the build when p95 latency or error rate crosses a budget.
- You're comparing two implementations or two deploy environments fairly.
Example output
Expect a set of test scripts in [load_test_tool] syntax — one per scenario — plus test-data generation, environment configuration, and a results-analysis template with graphs. Each script encodes its own load profile and asserts against the performance budgets, and the CI configuration shows how thresholds map to pass/fail. The custom metrics like checkout completion rate are defined alongside the standard latency and error-rate checks.
Pro tips
- Make
[api_description]concrete — list the real endpoints and flow (products, cart, checkout) so the scenarios mirror genuine user journeys, not isolated calls. - Set
[p95_target]and[error_target]from data you can defend; arbitrary budgets either never fail or always fail, and both are useless in CI. - Match
[concurrent_users]and[spike_users]to real or projected traffic — testing at numbers you'll never see wastes time and scares people. - Keep think time in the scenarios; without it you measure an unrealistic worst case that no real user produces.
- Define
[custom_metrics]that map to business outcomes (cart abandonment, checkout completion) so a passing test means the funnel works, not just that bytes moved. - Run the soak test for the full
[soak_duration]in a staging environment, not your laptop, since leaks need time and stable resources to surface.
