Find your system's limits with k6

Welcome to the Grafana learning path that builds on Run your first k6 performance test and Establish a performance baseline with k6. A baseline captures how your system behaves under expected load. This path goes further: you design stress profiles above that baseline to watch degradation, then optionally use breakpoint testing on a dedicated stack to find an outer bound where your thresholds stop the run. By the end, you map those results to a capacity envelope and one operational decision, for example an autoscale trigger or alert threshold.

Why QuickPizza?

Stress and breakpoint scripts in this path target the QuickPizza demo app, the same HTTPS endpoint used in the earlier k6 learning paths. That lets you focus on load profiles, checks, thresholds, and k6 summary output without standing up your own infrastructure first.

QuickPizza is a resilient shared demo target. Your stress run may complete with no visible degradation, and a breakpoint ramp may finish without an abortOnFail stop; both are valid outcomes here. You still practice staged ramps, read compact summary output, and document what you observed. When you need numbers that reflect your system’s limits, replace the URL with your own service endpoint in a dedicated test environment (required for meaningful breakpoint work).

Before you begin

Before you find your system’s limits, ensure that you have:

• A code editor and terminal with k6 installed. Refer to Install k6.
• A baseline k6 script with checks and thresholds that you can extend above expected load.

Pick approaches that match what you can safely load-test:

• Stress milestones: appropriate on shared or demo targets such as QuickPizza; allow about 15–20 minutes including script work and test runs.
• Breakpoint milestones: dedicated test stacks only; turn off autoscaling on affected components so elasticity does not mask the limit. The example ramp adds about 10 minutes of test runtime (shorten while learning). Refer to Breakpoint testing.
• Optional path: you can stop after the stress milestones and return for breakpoint work when you have an isolated environment.

Here’s what to expect

When you complete this path, you’ll be able to:

• Explain stress versus breakpoint testing and choose each for your environment
• Design and run a stress profile above baseline, read degradation signals in k6 output, and document results, including clean runs when QuickPizza stays healthy within your profile
• Build a breakpoint script with ramping-arrival-rate and abortOnFail, and record load at test stop
• Map results to a capacity envelope and apply them to one operational decision, for example autoscaling, alerts, or latency headroom

Troubleshooting

If you get stuck, we’ve got your back! Where appropriate, troubleshooting information is just a click away.

More to explore

We understand you might want to explore other capabilities not strictly on this path. We’ll provide you opportunities where it makes sense.