Course overview on Grafana Labs

Course overview

Fri, 05 Jun 2026 12:46:32 -0400

After this course you can

Run k6 run against QuickPizza and read latency, throughput, and errors in the terminal summary.
Execute k6 cloud run and open the stored run in Grafana Cloud k6.
Add checks, thresholds, and staged load so a re-run passes or fails from what you measured.

Who this course is for

Developers who want to catch performance regressions before they ship
QA engineers who need repeatable, automated performance validation for releases
Site reliability engineers (SREs) and platform engineers who need measured capacity data instead of guesses
Anyone who has wondered “how fast is fast enough?” for their system

What this course delivers

You are done when:

Local run: Your QuickPizza script finishes with k6 run and you can read latency and errors from the end-of-test summary.
Cloud run: At least one k6 cloud run completes and you can open that run in Grafana Cloud k6.
Baseline: The second path is complete—thresholds come from what you measured, and a re-run passes or fails on purpose (not by accident).

Hands-on — complete in order:

Run your first k6 performance test: Install k6, write the QuickPizza script, run k6 run locally, connect the CLI to Grafana Cloud, then run k6 cloud run.
Establish a performance baseline with k6: Shape load with stages, add checks, run without thresholds, set thresholds from measurements, re-run until stable, then review in Grafana Cloud k6.

You also leave with checks, a staged load profile, and a script you can reuse beside your application code. For documentation after the course, use Grafana Cloud k6 and the Where to go next slide.

Know the problems you are solving

This course uses HTTP metrics and thresholds so performance regressions surface before users do, with a clear pass-or-fail line you can use in reviews, QA sign-off, and pre-release checks. For symptoms teams recognize and how developers, QA, and SREs typically use k6, refer to Who uses performance testing?.

Course duration

~25-35 minutes (hands-on time varies with reading speed)

Performance testing with k6

Fri, 05 Jun 2026 12:46:32 -0400

The k6 vocabulary

For the performance tests in this course’s learning paths, k6 derives latency, throughput, and error metrics from the HTTP requests your script makes. Checks only appear when you define them; this course adds checks on every path. The table below explains these metrics.

Metric	What it measures	How k6 reports it
Latency (`http_req_duration`)	Response time per request	Percentiles: p50, p90, p95, p99
Throughput (`http_reqs`)	How much HTTP traffic your script generated	Total request count; summary also shows average rate (per second)
Error rate (`http_req_failed`)	Percentage of failed requests	Rate (0.00 = no errors)
Checks	Response assertions (correctness, not just speed)	Pass rate when your script defines checks

Percentiles (p50, p90, p95, p99) summarize how most requests behaved on the slow end; this course leans on p95 for thresholds. Refer to HTTP metrics when you need the full set of aggregates.

Thresholds, exit codes, and CI

In k6, thresholds on built-in metrics yield a clear pass or fail for the run, and a breach exits with code 99 so a continuous integration job can stop the pipeline without a human reading graphs first. You usually set those thresholds from goals you already use in operations, for example a p95 latency budget for an API or page-backed route, and a cap on error rate so timeouts and failed responses stay rare under representative load. That pairing of scripted limits and a process exit code is how this course automates quality gates; other load-testing tools expose their own failure and reporting models, and many also support response assertions similar to k6 checks.

The testing spectrum

Other common test types compare results against your baseline. That is why baseline comes first.

Test type	Question it answers	This course?
Baseline	“What does normal look like?”	Yes – Module 3
Stress	“Where does performance degrade?”	No – see k6 test types
Spike	“Can we survive a sudden traffic burst?”	No – see k6 test types
Soak	“Does anything break over hours?”	No – see k6 test types

Who uses performance testing?

Fri, 05 Jun 2026 12:46:32 -0400

Three roles, three questions

The same HTTP metrics support goals you already talk about in incidents and planning: end users waiting on slow responses, clients or gateways hitting timeout limits, and 5xx or failed requests when concurrency looks normal. k6 does not replace real user monitoring (collecting performance data from actual user sessions in production) or browser testing, but it does give you a repeatable load script and numbers you can gate on.

These are simplified labels; real teams mix responsibilities. The point is the question each workflow optimizes for, not that only one role may open an editor.

Role	Question they need answered	Typical k6 touchpoint	Outcome you might see
Developer	Did my change regress latency or errors before it lands on main?	k6 run in CI on the branch with thresholds on `http_req_duration` / `http_req_failed`	Merge blocked when p95 or error rate crosses a defined line
QA / release validation	Is this build within the same performance envelope as the last release?	Scheduled or on-demand k6 run against staging, compare runs in Grafana Cloud	Release note or ticket when a metric drifts beyond an agreed budget
SRE / platform	What is normal load and latency, and how much margin do we have before an event?	Baseline against production-like traffic, then capacity or incident follow-up outside this intro course	Autoscaling, limits, or comms grounded in measured steady state

Where you’ll start

This course teaches the skills all three workflows share: writing a test, setting thresholds, and establishing a baseline that produces an automated pass or fail verdict. How you apply those skills depends on your role: in merge review, release validation, or capacity planning.

Where k6 fits

Fri, 05 Jun 2026 12:46:32 -0400

k6 in the development workflow

k6 is an open-source performance testing tool: JavaScript test scripts, CLI runs, optional Grafana Cloud k6 execution and dashboards, and CI/CD integration via exit codes and thresholds.

Develop: Write test scripts in JavaScript alongside application code.
Run locally: Use k6 run locally or on a build agent for an instant end-of-test summary.
Run in Grafana Cloud k6: Use k6 cloud run for stored runs and dashboards. Refer to Grafana Cloud k6.
Automate: Reuse the same script in CI/CD; thresholds produce pass/fail without opening a UI.

For a fuller comparison of local k6 run and k6 cloud run, including commands and optional streaming to Grafana Cloud, refer to Local vs cloud execution.

Prerequisites

Fri, 05 Jun 2026 12:46:32 -0400

What you’ll need

Grafana Cloud account: Free tier is enough. Create an account if you need one. Use it to sign in and open k6 dashboards. A path will prompt you to authorize the CLI.
JavaScript basics: Variables, functions, imports. Nothing advanced. If you can read code, you can follow.
Code editor: Visual Studio Code or Cursor recommended.
Terminal access: Command line interface for running k6.

If JavaScript feels rusty

The learning paths use small scripts you can follow line by line. If you prefer help authoring or refactoring JavaScript, use Grafana Assistant in k6 Script Authoring mode in Grafana Cloud:

On the main menu, click Testing & synthetics > Performance.
Click the Assistant icon at the top of the sidebar to open the Grafana Assistant.
In the mode selector at the bottom of the Assistant panel, choose k6 Script Authoring.

Grafana Assistant must be enabled on your stack; contact your administrator if you do not see Assistant. Refer to Use k6 Script Authoring mode for workflows, prompts, and limitations.

Example prompt (paste into Assistant, then treat the reply as a draft—not the final script):

Create a minimal k6 HTTP test for https://quickpizza.grafana.com that checks for a 200 response, uses sleep(1) between iterations, and runs for 10 iterations.

Compare whatever Assistant returns with the script.js in the learning path before you run k6 run. Wording and structure can vary by stack and model version, so this course does not embed a fixed generated script here.

Installed during the course

You don’t need to install these in advance. The first learning path covers installation.

The first learning path installs k6, the performance testing CLI. The same binary sends results to Grafana Cloud. The paths cover login or a token when you need it. Refer to install k6 and Grafana Cloud k6 for details.

No test environment needed

You’ll test against QuickPizza. It’s a Grafana-maintained demo. You don’t need staging or production access to finish the paths.

Other entry points

Not starting from install and baseline? Use these instead:

Already comfortable with k6 thresholds and want stress, spike, or soak first? k6 test types
Browser-centric testing: k6 Browser
Little or no code: k6 Studio