---
title: "Apply the pattern to your own service | Grafana Labs"
description: "Move from QuickPizza to your own endpoint with a lightweight checklist and realistic tradeoffs"
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

## 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:

1. **Pick the target:** one critical GET or POST and a success condition you can assert in a check.
2. **Copy the QuickPizza script shape:** `options`, `default` function, at least one `http` call and a `sleep` that matches realistic pacing.
3. **Run once without thresholds** at a modest VU count; note **p95**, **http\_req\_failed**, and throughput from the summary (or Grafana Cloud k6).
4. **Set thresholds** with headroom on p95 and a cap on error rate; re-run until two consecutive runs agree.
5. **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.