Wrap-up on Grafana Labs

Course wrap-up

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

Course wrap-up

What you learned in Module 3:

How to design a load profile with stages
How to write checks for per-response correctness
How to set thresholds from what you measured (not from guesses)
How a baseline run produces a deliberate pass or fail verdict

What you’ll do in this module:

Transfer exercise — Apply the QuickPizza pattern to a service your team owns
Where to go next — Stress, spike, soak, and reference docs

Estimated time: 5 minutes for wrap-up content; 15-30 minutes for the transfer exercise

Apply the pattern to your own service

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

Scenario

Your team ships a read-heavy API or a page that fans out to several HTTP calls. In reviews, someone asks: “Are we sure this stays fast enough when traffic is normal Monday morning, not just on a developer laptop?” You want the same observe, set, validate loop you used on QuickPizza, but the URL, auth, and risk profile are yours.

Tradeoffs to decide explicitly

Choice	Upside	Cost or risk
Staging vs production-like	Safer for destructive mistakes	May miss real data shape, caches, or latency; document what is missing
Synthetic auth in `setup()`	Repeatable runs in CI	Tokens expire; secrets belong in secret stores, not the repo
Low VU count first	Fast feedback, easier debugging	Can miss concurrency bugs; raise VUs only after the script is stable
Tight vs loose p95 threshold	Tight catches small regressions	Too tight flakes on noise; loose misses real problems. Start from measured p95 plus headroom

What “good” looks like

One primary route in scope first (expand later). Everyone agrees which URL or user journey the gate protects.
Steady-state window long enough that p95 and error rate stop jumping run to run.
Checks assert something the business cares about (status, a required field), not only “200 OK.”
Thresholds came from numbers you observed, not a round number someone guessed.
Flaky gate = worse than no gate; if CI fails randomly, fix the profile or thresholds before enforcing.

Transfer exercise (15 to 30 minutes)

Do this once on a non-production URL your team owns:

Pick the target: one critical GET or POST and a success condition you can assert in a check.
Copy the QuickPizza script shape: options, default function, at least one http call and a sleep that matches realistic pacing.
Run once without thresholds at a modest VU count; note p95, http_req_failed, and throughput from the summary (or Grafana Cloud k6).
Set thresholds with headroom on p95 and a cap on error rate; re-run until two consecutive runs agree.
Write one line in your README or ticket: what the gate protects and what you would do if it fails.

That is enough to prove the skill transferred. When you expand, use your internal standards and the documentation on the Where to go next slide.

Where to go next

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

After baseline: stress, spike, soak

Level	Test type	Question	Where you are
Foundation	Baseline	“What does normal look like?”	You are here
Next	Stress	“Where does performance degrade?”	k6 test types
Next	Spike	“Can we survive a traffic burst?”	k6 test types
Next	Soak	“Does anything break over hours?”	k6 test types

Documentation

Grafana Cloud k6
k6 documentation
k6 results and outputs
k6 thresholds reference
k6 test types overview
API load testing: request rate (iteration rate versus HTTP request rate)
Open and closed models (how iteration timing couples to load)
k6 executors reference

Wrap-up on Grafana Labs

Course wrap-up

Course wrap-up

Apply the pattern to your own service

Scenario

Tradeoffs to decide explicitly

What “good” looks like

Transfer exercise (15 to 30 minutes)

Where to go next

After baseline: stress, spike, soak

Documentation

Community

Thank you

Thank you for completing this course!

Happy testing!