Generate a k6 Load Test Script with AI
Reads an endpoint description and returns a ready-to-run k6 script with `options.scenarios` (ramping-arrival-rate), thresholds for p95/p99/error rate, realistic think times, and a `handleSummary()` for exporting to Grafana / InfluxDB or k6 Cloud.
When to use it
- Adding a new endpoint to your load test suite.
- Migrating from JMeter or Locust to k6 for one or many endpoints.
- Bootstrapping load tests from an OpenAPI spec.
- Onboarding engineers to k6 — the script is annotated for learning.
The prompt
XML-tagged — best for Claude 4.x
<role>
You are a k6 specialist. You use modern k6 patterns: scenarios with executor, thresholds on percentiles + error rate, handleSummary() for output, check() inside requests. You reject the old "flat VUs + duration" pattern.
</role>
<context>
k6 v0.50+ recommends scenarios for any non-trivial test. Use `ramping-arrival-rate` for RPS targets, `ramping-vus` for VU-based loads. Thresholds belong in `options.thresholds`, NOT inline in check(). Always implement `handleSummary()` for exporting (default text output is unstructured).
</context>
<task>
For the endpoint below, generate a k6 script that includes:
1. `options.scenarios` block with the requested profile (ramp, spike, or steady)
2. `options.thresholds` for p95, p99, and error rate
3. The HTTP request with realistic headers (Content-Type, Authorization placeholder)
4. `check()` inside the request body for status + payload sanity
5. Realistic think time using `sleep()` with jitter
6. `handleSummary()` exporting JSON + a brief text summary
</task>
<input>
Endpoint description (method, URL, payload): {endpoint}
Load profile (steady, ramp, spike, soak): {profile}
Target RPS or VUs: {target}
SLA thresholds (p95, p99, error rate): {sla}
</input>
<constraints>
- k6 v0.50+ syntax: scenarios block, NOT flat VUs.
- Thresholds in options block, not inline.
- handleSummary() is MANDATORY.
- Think time uses `sleep(jitter)` with random variation (1-3s default unless specified).
- No `http.get('/some/url')` without options — always include headers.
- Add SharedArray for any test data (don't load JSON inline).
</constraints>
<output_format>
A single TypeScript/JavaScript code block with the full k6 script. Followed by a "Running it" section with: the exact `k6 run` command, expected output snippet, and 2-3 bullets on how to feed results to Grafana / k6 Cloud.
</output_format>
Before writing, decide which scenarios executor matches the requested profile.Example
Common pitfalls
- Model uses old VUs+duration syntax instead of scenarios — re-prompt with explicit v0.50+ reminder.
- Thresholds get embedded in check() instead of options.thresholds — they have different semantics. Demand options.thresholds for SLA gates.
- handleSummary gets omitted; default output is hard to consume downstream.
- Test data loaded inline as a literal array — fine for trivial cases, kills the script at scale. Use SharedArray for any non-trivial data.
Tips
- Always parameterize BASE_URL and AUTH_TOKEN via env vars; never commit creds.
- Add `tags` to requests so you can slice the dashboard by endpoint when you have multiple.
- Run with `--summary-trend-stats=avg,min,med,max,p(95),p(99),p(99.9)` for fuller percentile coverage.
- Pair with `design-load-test-strategy` to ensure the script's profile matches your overall strategy.
FAQ
Cloud: faster setup, dashboards included, distributed runs out of the box, $$$. Self-hosted: free but you wire Grafana yourself and run k6 from your own infra. Most teams should start with self-hosted + InfluxDB; move to Cloud when distributed runs become necessary.
Related prompts
Design a Load Test Strategy
Returns a load test strategy covering 5 scenario types (baseline / load / stress / spike / soak) with thresholds for response time, throughput, and error rate, environment requirements, monitoring checkpoints, and pass/fail criteria — and explicit environment-parity statement.
Open →Create a JMeter Test Plan
Returns a JMeter test plan as a valid .jmx-shaped XML skeleton with thread groups per scenario type, HTTP request samplers, response assertions, timers, and CSV-driven data — ready to import into JMeter 5.x for refinement and distributed runs.
Open →Analyze Performance Bottlenecks from Results
Reads a load test result summary (latency percentiles, throughput, error rate, system metrics) and returns a ranked list of suspected bottleneck layers — network, application, database, dependent service, or infrastructure — each with evidence cited from the metrics and a recommended next investigation step.
Open →Create API Test Suite from OpenAPI Spec
Reads an OpenAPI 3.x specification and returns an API test suite that validates response schemas per documented status code, covers authentication, pagination, filtering, and the standard error responses (400, 401, 403, 404, 429, 500). Output is framework-agnostic plan plus Playwright APIRequestContext skeleton.
Open →