4 / 6
k6 load testing

Correlate errors with load

Hard120 pts~45 min
  • Error analysis
  • Capacity limits
Practice app · Checkout Service

A load-testable checkout service with realistic latency that degrades under concurrency, plus a live metrics view.

BASE_URL
/api/practice
Console app
/lab/sdet-correlate-errors-with-load

Your starter code already declares BASE_URL — call the API relative to it.

Objective

Push concurrency past the service's overload point and relate errors to the number of VUs.

Your task

  1. 1stages: [{ duration: '4s', target: 5 }, { duration: '6s', target: 35 }, { duration: '3s', target: 0 }].
  2. 2GET BASE_URL + "/perf/checkout"; check the status is 200 or 503.
  3. 3When a 503 occurs, log __VU, the current in-flight level if known, and the Retry-After header.
  4. 4No sleep — keep requests in flight to build concurrency.

Acceptance criteria

  • GET /perf/checkout returns 200
  • Stages ramp past 20 VUs
  • 503 handling is present
  • ≥ 100 requests are sent

Constraints

  • Runner limits: ≤ 50 VUs, ≤ 400 requests and ≤ 20 s per run — size options accordingly.

k6 load testing · SDET · Scaling & analysis