API Performance Test Planner
Translate documented traffic and service objectives into a controlled workload.
Inputs and evidence
Require the authorized target environment, endpoint mix, traffic evidence, service objectives,
dependencies, test-data strategy, and current baseline if available. Record missing rates,
latency objectives, error budgets, or capacity expectations as TBD.
Workflow
- Select only the requested test type: baseline, load, stress, spike, or soak.
- Derive virtual users or request rate, traffic mix, ramp, and duration from supplied evidence.
- Define checks and thresholds from documented SLOs; keep absent thresholds
TBD.
- Specify synthetic data, correlation, server-side monitoring, network context, and cleanup.
- Draft the requested k6 or JMeter artifact with configurable rates, durations, and safe defaults.
- HUMAN REVIEW GATE (mandatory). Confirm target ownership, rates, duration, schedule,
data, monitoring, dependencies, and abort conditions before any load is generated.
Output shape
| Scenario |
VUs or RPS |
Ramp |
Duration |
Dataset |
Threshold source |
Abort condition |
Include assumptions, monitoring plan, execution prerequisites, and review decision.
Guardrails
- Never load-test production, a third party, or a shared environment without explicit authorization.
- Never invent traffic, pass/fail thresholds, baselines, bottlenecks, or execution results.
- Start with a reviewed smoke workload; enforce approved request and concurrency ceilings.
- Redact credentials and personal data; use synthetic or approved anonymized datasets.
- Do not infer server capacity or root cause from client latency alone.
1---2name: api-performance-test-planner3description: Create a review-ready API performance plan and optional k6 or JMeter draft. Use when asked to plan load, stress, spike, soak, throughput, concurrency, or latency testing for APIs. Produce an evidence-based workload, thresholds, monitoring needs, and abort conditions without inventing an SLA or starting load automatically.4license: MIT5---67# API Performance Test Planner89Translate documented traffic and service objectives into a controlled workload.1011## Inputs and evidence1213Require the authorized target environment, endpoint mix, traffic evidence, service objectives,14dependencies, test-data strategy, and current baseline if available. Record missing rates,15latency objectives, error budgets, or capacity expectations as `TBD`.1617## Workflow18191. Select only the requested test type: baseline, load, stress, spike, or soak.202. Derive virtual users or request rate, traffic mix, ramp, and duration from supplied evidence.213. Define checks and thresholds from documented SLOs; keep absent thresholds `TBD`.224. Specify synthetic data, correlation, server-side monitoring, network context, and cleanup.235. Draft the requested k6 or JMeter artifact with configurable rates, durations, and safe defaults.246. **HUMAN REVIEW GATE (mandatory).** Confirm target ownership, rates, duration, schedule,25 data, monitoring, dependencies, and abort conditions before any load is generated.2627## Output shape2829| Scenario | VUs or RPS | Ramp | Duration | Dataset | Threshold source | Abort condition |30|---|---|---|---|---|---|---|3132Include assumptions, monitoring plan, execution prerequisites, and review decision.3334## Guardrails3536- Never load-test production, a third party, or a shared environment without explicit authorization.37- Never invent traffic, pass/fail thresholds, baselines, bottlenecks, or execution results.38- Start with a reviewed smoke workload; enforce approved request and concurrency ceilings.39- Redact credentials and personal data; use synthetic or approved anonymized datasets.40- Do not infer server capacity or root cause from client latency alone.
PramodDutta