{{ resultsReady ? 'Planned peak concurrency' : 'Request needs attention' }}
{{ summaryValue }}

{{ summaryLine }}

Request{{ method }} Profile{{ profile === 'smoke' ? 'Smoke' : profile === 'constant' ? 'Constant VUs' : 'Ramping VUs' }}
HTTP(S), one request. This page never contacts the target. All inputs stay in memory and are excluded from URLs and storage. Reload resets the draft.
VUs are concurrent users. Request time plus pacing controls iteration speed; this does not set a fixed request rate.
Placeholders only. Set K6_TOKEN, K6_BASIC_AUTH (base64 username:password), or K6_API_KEY in your own environment.
Headers:
At most 20 including auth and POST Content-Type. Use environment names for cookies, tokens and keys. POST adds Content-Type when absent.
Blank uses 1 second of sleep after each request. 0–60 seconds, steps of 0.1. This is additional delay, not a throughput guarantee.
s
Blank uses 10 seconds. From 1 to 60 seconds.
s
Blank expects exactly 200. From 100 to 599. Any unexpected status fails its check and counts as an HTTP failure.
Optional upper bound, inclusive. Blank omits this threshold. Request duration excludes initial connection setup.
ms
Used only when a latency threshold is entered.
Optional inclusive maximum, 0–100%, up to 3 decimals. Blank requires all status checks to pass. An entered limit replaces that strict gate with your HTTP failure tolerance.
%
{{ scriptText }}
  1. {{ line }}

Chart renderer unavailable. The script still contains the workload.

{{ timelineNote }}

ItemValueMeaningCopy
{{ row.item }}{{ row.value }}{{ row.meaning }}

Similar tools

An API can answer one request correctly and still slow down when several clients use it together. HTTP load testing repeats a request under a defined workload so that response times and failures can be compared under concurrent use. A k6 script records that request, the workload schedule, and the criteria a later run will be judged against. Writing the script establishes the test plan; running it supplies the measurements.

A virtual user, or VU, repeatedly performs an iteration of the test. In a single-request workload, that iteration contains the request, its checks, and any pause before repeating. VUs describe concurrent activity, not requests per second. With a closed-model workload, each VU finishes its current iteration before starting another. Slower responses therefore reduce the rate of new requests, even when the number of VUs stays unchanged.

Pacing adds a pause after a request completes. A one-second pause does not mean one request starts every second, because the request itself also takes time. A short trial at low concurrency can expose a wrong URL, missing authentication, or an unexpected status before a larger run. Holding concurrency steady helps compare repeated runs, while gradually raising and lowering it explores how behavior changes as concurrent use changes.

Check
An observation about an individual response, such as whether its status matches the expected value.
Threshold
A passing condition for a metric collected during the run, such as an acceptable failure fraction or response-time percentile.

Response-time percentiles describe different parts of the observed timing distribution. The 95th percentile, usually written p95, is a duration at or below which roughly 95% of recorded request times fall. It helps reveal slower responses that an average can hide, but is not the maximum response time. A latency requirement and a failure allowance answer different questions, so a run can meet one and miss the other.

Useful comparisons keep the request, payload, credentials, workload, and execution environment consistent. A matching status does not prove that returned data is correct, and a brief test of one endpoint does not establish the capacity of a whole application. Repeated POST requests can also create or change data, so the target and payload need to be suitable for deliberate, authorized testing.

How to Use This Tool:

Prepare one HTTP(S) request for a later k6 run. Changes update the generated script automatically; this page never sends the target request or executes a test.

  1. Enter your authorized target in Request URL, replacing the supplied example, and choose Method. For POST, choose JSON or Text and enter the body. GET and HEAD omit the body while retaining the POST draft.
  2. Choose Workload. Smoke provides a short initial run, Constant VUs holds a chosen concurrency, and Ramping VUs moves through your stage targets. Each ramp duration is the time spent reaching that stage's target.
  3. Open Advanced for authentication, headers, or different timing and pass/fail criteria. For sensitive custom headers, choose Environment variable as the value source and enter the variable name. Supply its actual value when you run k6.
  4. Review Request review and Workload timeline against the request and concurrency you intend to run.
    If Request needs attention appears, correct the displayed issue. For invalid POST JSON, repair the body or select Text when literal text is intended. The draft remains available, but the previous script and its exports are withdrawn until the inputs are valid.
  5. Copy the script or choose Download .js, then inspect the complete request before execution. With your own k6 installation and required environment variables ready, run the reviewed file using k6 run generate_k6_script.js.

Interpreting Results:

Planned peak concurrency is the largest configured VU count. The accompanying duration is the scheduled load window. Neither value measures server capacity, predicts throughput, or confirms that the target can be reached.

  • k6 script contains the complete generated JavaScript and configured request. Successful generation confirms that the entries meet the generator's rules; actual k6 execution is still needed to check authentication, connectivity, and runtime behavior.
  • Workload timeline shows planned VUs against elapsed seconds. Its CSV contains the start and end points for constant concurrency, or the starting point and stage endpoints for a ramp. Its image exports show the same schedule, not measured performance.
  • Request review summarizes request settings, body size, header count, criteria, and required environment names. Its CSV and DOCX exports contain that review, not the complete request source or a server response.

A Failure criterion of Not set does not mean that every outcome is acceptable. Leaving the HTTP failure threshold blank still requires every recorded status check to pass. An entered percentage replaces that strict requirement with the chosen HTTP failure allowance.

Timeline exports require the chart to be ready. If it cannot load, the script remains available and Retry chart lets you try loading the visualization again.

Technical Details:

Each generated iteration makes one HTTP request, checks its exact status, and then sleeps for the pacing interval. Redirects are disabled, so a redirect response is evaluated without following it. Response bodies are discarded, and the generated check does not inspect returned content or JSON fields.

Workload rules and scheduled time

The workload selects how many VUs repeat that iteration and for how long. These are limits of this generator, not maximum capabilities of k6.

Workload k6 executor Concurrency Scheduled seconds
Smoke constant-vus Fixed at 1 VU 30
Constant VUs constant-vus A fixed whole count from 1 to 100 VUs 1 to 600
Ramping VUs ramping-vus Whole starting and target counts from 1 to 100 VUs 1 to 600 total

A ramp contains one to five stages, each lasting a whole number of seconds from 1 to 600. Their combined duration cannot exceed 600 seconds. Stage durations accumulate from the start; they are not absolute timestamps. Every stage moves linearly from the preceding VU count to its target. A zero starting count or zero target is not accepted.

The total ramp duration is the sum of its stage durations.

T = ∑ i=1 n di

Here, T is the scheduled duration in seconds, n is the number of stages, and each d is a stage's duration in seconds. Peak concurrency includes the starting count as well as every stage target.

Vpeak = max ( V0 , V1 , … , Vn )

V₀ is the starting VU count and V₁ through Vₙ are stage targets. The timeline joins those planned values with straight lines. k6 runs whole VUs, so the line between targets is not a measurement of fractional users. Changing pacing leaves this schedule unchanged.

Pacing defaults to 1 second and accepts 0 to 60 seconds in 0.1-second increments. Zero removes the additional pause. The request timeout defaults to 10 seconds and accepts whole seconds from 1 to 60. Neither value sets a fixed request rate.

Every workload sets gracefulStop to "0s"; ramping also sets gracefulRampDown to "0s". An iteration can therefore be interrupted when its VU is removed or the load window ends, even before its request timeout expires. Process startup and shutdown are outside the scheduled load window.

Exact status and failure policy

The expected status defaults to 200 and accepts one whole status code from 100 to 599. A response must match that exact code. If 200 is expected, 201 is unexpected even though both are in the 2xx range. The same expected status is passed to http.expectedStatuses to define HTTP failure classification for http_req_failed. Network errors and timeouts can also produce failed requests.

A k6 check records its result without automatically making the process exit with a failure. The generated threshold supplies that pass/fail rule. Entering an HTTP failure percentage removes the strict threshold on checks while retaining the individual status checks as observations.

HTTP failure threshold Metric Generated expression Passing condition
Blank checks rate==1 Every recorded status check passes.
0% http_req_failed rate<=0 No recorded HTTP failures.
1.5% http_req_failed rate<=0.015 The HTTP failure fraction is at most 1.5%.
100% http_req_failed rate<=1 This criterion permits every recorded request to fail.

An entered failure percentage P is converted to the fraction used by k6.

rlimit = P100

The allowed input is 0 to 100%, in increments of 0.001 percentage points. Dividing by 100 produces a ratio with at most five decimal places, so 1.5% becomes 0.015. The upper bound is inclusive. A 100% allowance only relaxes the HTTP failure criterion; latency criteria or runtime errors can still make a run fail.

Latency criteria and timing units

A latency threshold accepts a whole number from 1 to 60,000 milliseconds and a percentile of p90, p95, or p99. The initial percentile is p95. Leaving the latency field blank omits this threshold; entering zero is invalid.

The metric http_req_duration includes sending the request, waiting for the response, and receiving it. It excludes initial DNS lookup and connection setup, as well as the scripted pacing pause. Its unfiltered samples are used, including requests classified as unexpected. For example, p(95)<=500 requires the calculated 95th percentile to be at most 500 ms, not every request to finish within 500 ms.

The selected failure policy and optional latency threshold must both pass. These thresholds determine the final test outcome; the generated script does not enable early termination when a threshold is crossed.

Request text and size limits

GET and HEAD generate a request without a body. Their retained POST draft is inactive, so malformed JSON in that draft does not block either method. POST JSON is checked for valid syntax, then preserved without reformatting or rewriting its contents. Text is preserved literally. POST adds Content-Type: application/json or Content-Type: text/plain only when no Content-Type header has been supplied.

Request size is counted in UTF-8 bytes. A character can occupy more than one byte, so a character count alone cannot establish whether a request fits.

Item Maximum What counts
Request URL 4,096 bytes The URL after surrounding whitespace is removed.
POST body 16 KiB / 16,384 bytes The entered JSON or text, including whitespace.
Configured headers 20 Custom headers, selected authentication, and any automatic Content-Type.
Generated JavaScript 64 KiB / 65,536 bytes The complete source, including escaped request text.

HTTP and HTTPS URLs are accepted without embedded username/password credentials, fragments, internal spaces, or control characters. Apart from trimming surrounding whitespace, the entered URL is retained, including its query encoding.

Quotes and other characters that need escaping are represented as string data in the generated JavaScript. This preserves the request text when the script runs, but can make the source larger than the body. A heavily escaped body can hit the 64 KiB source limit before reaching the 16 KiB body limit; shortening the request is then necessary.

Headers and authentication

Header names must be valid HTTP header names, at most 128 characters, and unique without regard to case. Entered literal header values are limited to 1,024 UTF-8 bytes without control characters. Host, Content-Length, Connection, and Transfer-Encoding are rejected because k6 manages those request details.

Authentication adds a header whose value comes from the execution environment. Selecting authentication and also entering the same header manually causes a duplicate-header error.

Authentication Environment name Required value and generated header
None None added No authentication header is added automatically.
Bearer K6_TOKEN The token without its prefix. The Bearer prefix is added to Authorization.
Basic K6_BASIC_AUTH Base64 of username:password, without the Basic prefix. That prefix is added to Authorization.
X-API-Key K6_API_KEY The key used directly as the X-API-Key header value.

Custom headers can also use environment variables. Environment variable names contain 1 to 64 uppercase letters, digits, or underscores and begin with a letter or underscore. Values are read through __ENV, and a guard stops the generated script if a required value is missing or empty. It does not verify that the supplied credential is valid.

Headers whose names indicate authorization, cookies, tokens, API keys, secrets, or passwords must use an environment variable instead of literal text. This name check does not detect every possible secret. Authentication and automatic Content-Type count toward the final 20-header limit, so 20 custom headers may already leave no room for the headers a POST request adds.

Privacy and Execution:

All request and workload inputs stay in browser memory, including duration, pacing, and thresholds. They are not restored from or written into the page address, local or session storage, draft history, or saved presets. Reloading resets the draft and all settings.

  • Ordinary page and chart assets still load over the network. Local generation does not promise that the whole page works offline.
  • The generated script contains the entered URL, any active POST body, and literal header values. Copying, downloading, or sharing it carries that information with it. An environment reference defers supplying a value until execution; it does not encrypt the script or redact other entered data.
  • No server proxy, target scan, cloud load test, or installed k6 runtime is supplied. A later run uses your chosen environment to send the configured request. The generated workload covers one HTTP request, without multiple-request journeys, browser automation, or arrival-rate scheduling.

Worked Examples:

Reviewing the starting GET request

The supplied example starts with GET and Smoke, producing 1 VU for 30 seconds. Its timeline runs from 1 VU at 0 seconds to 1 VU at 30 seconds. The request has no body or added headers, expects exactly status 200, allows a 10-second request timeout, and sleeps for 1 second after each request. Blank optional criteria leave the strict checks threshold rate==1 in place and omit a latency threshold. The example target must be replaced before an intended run; these settings do not establish how many requests will complete.

Changing to a POST ramp with a failure allowance

Choose POST with JSON body {"x":"a"}, start at 1 VU, then set stages of 10 seconds to 5 VUs and 20 seconds to 2 VUs. The body is 9 UTF-8 bytes and receives an automatic Content-Type: application/json header. The planned points are (0 seconds, 1 VU), (10 seconds, 5 VUs), and (30 seconds, 2 VUs), giving a 30-second window and a peak of 5 VUs. With pacing of 0.5 seconds, p95 latency of 500 ms, and a 1.5% HTTP failure allowance, the source includes sleep(0.5), p(95)<=500, and rate<=0.015. It still checks exact status 200, but no longer requires every status check to pass. The later run must meet both configured thresholds; nothing in the planned curve claims that it will.

References: