What is k6?

k6 is an open-source performance testing tool built by Grafana Labs. Unlike JMeter (XML config) or Locust (Python), k6 tests are written in JavaScript — making them feel like unit tests to frontend and backend developers alike.

Quick Start

brew install k6   # macOS
# or: docker run grafana/k6

k6 run script.js

// script.js
import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  vus: 100,         // 100 virtual users
  duration: '30s',  // for 30 seconds
};

export default function () {
  const res = http.get('https://api.example.com/users');
  check(res, { 'status is 200': (r) => r.status === 200 });
  sleep(1);
}

Key Metrics

k6 tracks: http_req_duration (p50/p90/p95/p99), http_req_failed, vus, iterations, data_received, and custom metrics you define.

k6 vs Alternatives

	k6	Locust	Artillery	JMeter
Script language	JavaScript	Python	YAML/JS	XML
Performance	Excellent	Good	Good	Moderate
CI/CD	Native	Good	Native	Plugin
GUI	No	Yes	No	Yes

Best For

API load testing in CI/CD pipelines
Teams that prefer code-over-config
Developers who want Grafana integration for metrics visualization

Use Cases

Performance gates in CI/CD: k6 integrates natively with GitHub Actions, GitLab CI, and Jenkins. Add a performance stage to your pipeline that runs a 30-second load test after deployment and fails if p95 latency exceeds your SLA threshold — catching regressions before they reach users.

Threshold-based testing: Define explicit pass/fail criteria in your script options so tests fail the CI build automatically:

export const options = {
  thresholds: {
    http_req_duration: ['p(95)<500'],   // 95th percentile under 500ms
    http_req_failed: ['rate<0.01'],      // error rate under 1%
  },
};

Grafana dashboards for ongoing monitoring: Feed k6 metrics to a Grafana Cloud or self-hosted Grafana stack via InfluxDB or Prometheus. Use k6 run --out influxdb=http://localhost:8086/k6 script.js to stream real-time metrics during test execution for detailed visualization.

Browser-based load testing: The k6/browser module extends k6 to simulate real browser sessions using Playwright under the hood — letting you combine protocol-level API tests with user-journey browser tests in a single script. This is useful for testing pages that do heavy client-side rendering.

Advanced: Scenarios and Executors

k6’s scenario system gives precise control over virtual user behavior:

export const options = {
  scenarios: {
    api_spike: {
      executor: 'ramping-vus',
      stages: [
        { duration: '30s', target: 10 },   // warm up
        { duration: '1m', target: 200 },   // spike
        { duration: '30s', target: 0 },    // cool down
      ],
    },
    background_traffic: {
      executor: 'constant-vus',
      vus: 20,
      duration: '2m',
      exec: 'backgroundFlow',
    },
  },
};

Concrete Use Case: Gating Production Deployments on P99 Latency SLOs in GitHub Actions

A payment processing team maintains a REST API that serves checkout sessions for an e-commerce platform. Their SLO requires that P99 response latency stays below 300ms and error rates remain under 0.1%. Before adopting k6, performance regressions slipped into production regularly — a new serialization layer doubled P95 latency, but nobody noticed until customer complaints spiked. The team needed an automated gate that blocks deployments when latency budgets are exceeded.

They integrated k6 directly into their GitHub Actions deployment workflow. After the build and unit test stages pass, a dedicated load-test job spins up, pulls the latest container image into a staging environment, and executes a k6 script that simulates 200 concurrent virtual users hitting the /v1/checkout, /v1/payment, and /v1/receipt endpoints for 60 seconds. The k6 script defines explicit thresholds — http_req_duration: ['p(99)<300'] and http_req_failed: ['rate<0.001'] — so the process exits with a non-zero code if any threshold is breached. The GitHub Actions workflow is configured with if: success() on the subsequent deploy step, meaning a failed load test halts the entire release pipeline. Test result summaries, including P50/P90/P95/P99 latency breakdowns and throughput numbers, are posted as a PR comment via the k6-reporter action for immediate visibility.

To keep the feedback loop fast, the team uses k6’s ramping-vus executor to ramp from 0 to 200 users over 15 seconds, sustain peak load for 30 seconds, then ramp back down — completing the entire test in under a minute. They also stream k6 metrics to a Grafana Cloud dashboard via the --out cloud flag, giving them historical trend data across releases. When a developer’s PR causes P99 to jump from 180ms to 420ms, the pipeline blocks the merge and the Grafana dashboard clearly shows the regression point. This approach has eliminated latency-related production incidents and gives the team confidence to ship multiple times per day.

When to Use k6

Use k6 when:

You need load testing scripts versioned alongside application code in the same repository, written in JavaScript/TypeScript that developers already know
Your CI/CD pipeline requires automated performance gates with explicit pass/fail thresholds on latency percentiles, error rates, or custom metrics
You want lightweight, fast test execution without JVM startup overhead or heavy GUI tooling — k6’s Go runtime handles thousands of virtual users with minimal resource consumption
Your observability stack includes Grafana, InfluxDB, or Prometheus and you want native metric streaming for real-time dashboards and historical trend analysis
You need to combine protocol-level HTTP load tests with browser-based user journey tests using the k6/browser module in a single testing framework

When NOT to use k6:

You need a visual, point-and-click test builder for non-developer team members — k6 is code-only with no built-in GUI for test creation, so tools like JMeter or Gatling’s recorder may be more accessible
Your load testing requirements demand distributed execution across multiple geographic regions and you do not have a Grafana Cloud subscription — orchestrating distributed k6 runs self-hosted requires significant infrastructure setup
You are testing exclusively at the browser/UI level without any API or protocol-level concerns — dedicated browser testing tools like Playwright or Cypress are more appropriate for pure end-to-end UI testing
Your team primarily uses Python and prefers writing test logic in Python — Locust provides a similar developer-centric load testing experience with a Python-native API

k6 — Modern Load Testing Tool for Developers

✅ Pros

⚠️ Cons