Load test types on Grafana Labs

Smoke testing

Mon, 21 Sep 2026 15:16:28 +0000

Smoke testing

Smoke tests have a minimal load. Run them to verify that the system works well under minimal load and to gather baseline performance values.

This test type consists of running tests with a few VUs — more than 5 VUs could be considered a mini-load test.

Similarly, the test should execute for a short period, either a low number of iterations or a duration from seconds to a few minutes maximum.

In some testing conversation, smoke tests are also called shakeout tests.

When to run a Smoke test

Teams should run smoke tests whenever a test script is created or updated. Smoke testing should also be done whenever the relevant application code is updated.

It’s a good practice to run a smoke test as a first step, with the following goals:

Verify that your test script doesn’t have errors.
Verify that your system doesn’t throw any errors (performance or system related) when under minimal load.
Gather baseline performance metrics of your system’s response under minimal load.
With simple logic, to serve as a synthetic test to monitor the performance and availability of production environments.

Considerations

When you prepare a smoke test, consider the following:

Each time you create or update a script, run a smoke test

Because smoke tests verify test scripts, try to run one every time you create or update a script. Avoid running other test types with untested scripts.
Keep throughput small and duration short

Configure your test script to be executed by a small number of VUs (from 2 to 20) with few iterations or brief durations (30 seconds to 3 minutes).

Smoke testing in k6

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

export const options = {
  vus: 3, // Key for Smoke test. Keep it at 2, 3, max 5 VUs
  duration: '1m', // This can be shorter or just a few iterations
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  check(urlRes, { 'status returned 200': (r) => r.status == 200 })
  sleep(1);
  // MORE STEPS
  // Here you can have more steps or complex script
  // Step1
  // Step2
  // etc.
};

The following script is an example smoke test. You can copy it, change the endpoints, and start testing. For more comprehensive test logic, refer to Examples. The VU chart of a smoke test should look similar to this.

Results analysis

The smoke test initially validates that your script runs without errors. If any script-related errors appear, correct the script before trying any more extensive tests.

On the other hand, if you notice poor performance with these low VU numbers, report it, fix your environment, and try again with a smoke test before any further tests.

Once your smoke test shows zero errors and the performance results seem acceptable, you can proceed to other test types.

Average-load testing

Mon, 21 Sep 2026 15:16:28 +0000

Average-load testing

An average-load test assesses how the system performs under typical load. Typical load might be a regular day in production or an average moment.

Average-load tests simulate the number of concurrent users and requests per second that reflect average behaviors in the production environment. This type of test typically increases the throughput or VUs gradually and keeps that average load for some time. Depending on the system’s characteristics, the test may stop suddenly or have a short ramp-down period.

Since “load test” might refer to all types of tests that simulate traffic, this guide uses the name average-load test to avoid confusion. In some testing conversation, this test also might be called a day-in-life test or volume test.

Start your learning experience with Grafana Learning Paths

Grafana Learning Paths provide a clear, structured path that leads you from beginner concepts to advanced use cases. Learn about this Grafana feature on Establish a performance baseline with k6.

Start learning

When to run an average-load test

Average-Load testing helps understand whether a system meets performance goals on a typical day (commonplace load). Typical day here means when an average number of users access the application at the same time, doing normal, average work.

You should run an average-load test to:

Assess the performance of your system under a typical load.
Identify early degradation signs during the ramp-up or full load periods.
Assure that the system still meets the performance standards after system changes (code and infrastructure).

Considerations

When you prepare an average-load test, consider the following:

Know the specific number of users and the typical throughput per process in the system.

To find this, look through APMs or analytic tools that provide information from the production environment. If you can’t access such tools, the business must provide these estimations.
Gradually increase load to the target average.

That is, use a ramp-up period. This period usually lasts between 5% and 15% of the total test duration. A ramp-up period has many essential uses:
- It gives your system time to warm up or auto-scale to handle the traffic.
- It lets you compare response times between the low-load and average-load stages.
- If you run tests using our cloud service, a ramp up lets the automated performance alerts understand the expected behavior of your system.
Maintain average for a period longer than the ramp up.

Aim for an average duration at least five times longer than the ramp-up to assess the performance trend over a significant period of time.
Consider a ramp-down period.

The ramp down is when virtual user activity gradually decreases. The ramp down usually lasts as long as the ramp up or a bit less.

Average-load testing in k6

Note
If this is your first time running load tests, we recommend starting small or configuring the ramp-up to be slow. Your application and infrastructure might not be as rock solid as you think. We’ve had thousands of users run load tests that quickly crash their applications (or staging environments).

The goal of an average-load test is to simulate the average amount of activity on a typical day in production. The pattern follows this sequence:

Increase the script’s activity until it reaches the desired number of users and throughput.
Maintain that load for a while
Depending on the test case, stop the test or let it ramp down gradually.

Configure load in the options object:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  // Key configurations for avg load test in this section
  stages: [
    { duration: '5m', target: 100 }, // traffic ramp-up from 1 to 100 users over 5 minutes.
    { duration: '30m', target: 100 }, // stay at 100 users for 30 minutes
    { duration: '5m', target: 0 }, // ramp-down to 0 users
  ],
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
  // MORE STEPS
  // Here you can have more steps or complex script
  // Step1
  // Step2
  // etc.
};

This script logic has only one request (to open a web page). Your test behavior likely has more steps. If you would like to see more complex tests that use groups, checks, thresholds, and helper functions, refer to Examples.

The VU or throughput chart of an average-load test looks similar to this:

Results analysis

An initial outcome for the average-load test appears during the ramp-up period to find whether the response time degrades as the load increases. Some systems might even fail during the ramp-up period.

The test validates if the system’s performance and resource consumption stay stable during the period of full load, as some systems may display erratic behavior in this period.

Once you know your system performs well and survives a typical load, you may need to push it further to determine how it behaves at above-average conditions. Some of these above-average conditions are known as Stress tests.

Stress testing

Mon, 21 Sep 2026 15:16:28 +0000

Stress testing

Stress testing assesses how the system performs when loads are heavier than usual.

The load pattern of a stress test resembles that of an average-load test. The main difference is higher load. To account for higher load, the ramp-up period takes longer in proportion to the load increase. Similarly, after the test reaches the desired load, it might last for slightly longer than it would in the average-load test.

In some testing conversation, stress tests might also be called rush-hour, surge, or scale tests.

Start your learning experience with Grafana Learning Paths

Grafana Learning Paths provide a clear, structured path that leads you from beginner concepts to advanced use cases. Learn about this Grafana feature on Find your system’s limits with k6.

Start learning

When to perform a Stress test

Stress tests verify the stability and reliability of the system under conditions of heavy use. Systems may receive higher than usual workloads on unusual moments such as process deadlines, paydays, rush hours, ends of the workweek, and many other behaviors that might cause frequent higher-than-average traffic.

Considerations

When you run a stress test, consider the following:

Load should be higher than what the system experiences on average.

Some testers might have default targets for stress tests—say an increase upon average load by 50 or 100 percent—there’s no fixed percentage.

The load simulated in a Stress test depends on the stressful situations that the system may be subject to. Sometimes this may be just a few percentage points above that average. Other times, it can be 50 to 100% higher, as mentioned. Some stressful situations can be twice, triple, or even orders of magnitude higher.

Define load according to the risk load patterns that the system may receive.

Only run stress tests after running average-load tests.

Identify performance issues under average-load tests before trying anything more challenging. This sequence is essential.

Re-use the Average-Load test script.

Modify the parameters to have higher load or VUs.
Expect worse performance compared to average load.

This test determines how much the performance degrades with the extra load and whether the system survives it. A well-performant system should respond with consistent response times when handling a constant workload for an extended period.

Stress testing in k6

The load in a stress test resembles load in an average-load test. The difference is that it reaches a higher level of load.

Increase the script’s activity further in a slower ramp-up until it reaches an above-average number of users or throughput.
Maintain that load for a while.
Depending on the test case, stop or ramp down gradually.

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  // Key configurations for Stress in this section
  stages: [
    { duration: '10m', target: 200 }, // traffic ramp-up from 1 to a higher 200 users over 10 minutes.
    { duration: '30m', target: 200 }, // stay at higher 200 users for 30 minutes
    { duration: '5m', target: 0 }, // ramp-down to 0 users
  ],
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
  // MORE STEPS
  // Here you can have more steps or complex script
  // Step1
  // Step2
  // etc.
};

For more complex behavior, refer to Examples.

The VU or throughput chart of a Stress test looks similar to this:

Note that in the same way as the average-load test, the Stress test starts at 0 and increases beyond the point tested in the average-load type. The ramp-up and ramp-down periods are longer to allow a more realistic response.

Note
Run stress tests only after smoke and average-load tests. Running this test type earlier may be wasteful and make it hard to pinpoint problems if they appear at low volumes or at loads under the average utilization.

Results analysis

Like the average-load test, an initial outcome for the Stress test shows up during the ramp-up period to identify response time degradation as the load increases further than the average utilization. Commonly, the performance degrades, and even the system’s stability crashes as we push the system further than the average-load test.

During the full load period, verification is vital if the system’s performance and resource consumption stays stable with a higher load.

Now that you know that your system can handle outstanding load events, the teams generally check if the system performs well over extended periods. That is, they run a Soak test.

Soak testing

Mon, 21 Sep 2026 15:16:28 +0000

Soak testing

Soak testing is another variation of the Average-Load test. It focuses on extended periods, analyzing the following:

The system’s degradation of performance and resource consumption over extended periods.
The system’s availability and stability during extended periods.

The soak test differs from an average-load test in test duration. In a soak test, the peak load duration (usually an average amount) extends several hours and even days. Though the duration is considerably longer, the ramp-up and ramp-down periods of a soak test are the same as an average-load test.

In some testing conversation, a soak test might be called an endurance, constant high load, or stamina test.

Start your learning experience with Grafana Learning Paths

Grafana Learning Paths provide a clear, structured path that leads you from beginner concepts to advanced use cases. Learn about this Grafana feature on Test system endurance with k6 soak testing.

Start learning

When to perform a Soak test

Most systems must stay turned on and keep working for days, weeks, and months without intervention. This test verifies the system stability and reliability over extended periods of use.

This test type checks for common performance defects that show only after extended use. Those problems include response time degradation, memory or other resource leaks, data saturation, and storage depletion.

Considerations

When you prepare to run a soak test, consider the following:

Configure the duration to be considerably longer than any other test.

Some typical values are 3, 4, 8, 12, 24, and 48 to 72 hours.
If possible, re-use the average-load test script

Changing only the peak durations for the aforementioned values.
Don’t run soak tests before running smoke and average-load tests.

Each test uncovers different problems. Running this first may cause confusion and resource waste.
Monitor the backend resources and code efficiency. Since we are checking for system degradation, monitoring the backend resources and code efficiency is highly recommended. Of all test types, backend monitoring is especially important for soak tests.

Soak testing in k6

The soak test is almost the same as the average-load test. The only difference is the increased duration of the load plateau.

Increase the load until it reaches an average number of users or throughput.
Maintain that load for a considerably longer time.
Finally, depending on the test case, stop or ramp down gradually.

Configure the load duration in the options object:

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  // Key configurations for Soak test in this section
  stages: [
    { duration: '5m', target: 100 }, // traffic ramp-up from 1 to 100 users over 5 minutes.
    { duration: '8h', target: 100 }, // stay at 100 users for 8 hours!!!
    { duration: '5m', target: 0 }, // ramp-down to 0 users
  ],
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
  // MORE STEPS
  // Here you can have more steps or complex script
  // Step1
  // Step2
  // etc.
};

For more complex behavior, refer to Examples.

Notice that, as in an average-load test, peak load plateaus at 100. VUs. The difference is in duration. In this soak, peak load maintains for 8 hours rather than some minutes.

Results analysis

If we execute this test after the previous types, we should have a system performing well under previous scenarios. In this test, monitor for changes in any performance metric as time passes. Try to correlate any impact with backend measurement changes that indicate degradation over time. Such changes can be gradual degradations, as mentioned, and sudden changes (improvements, too) in response time and backend hardware resources. Backend resources to check are RAM consumed, CPU, Network, and growth of cloud resources, among others.

The expected outcome is that the performance and resource utilization of the backend stays stable or within expected variations.

After you run all the previous test types, you know your system performs well at many different loads: small, average, high, and extended.

Spike testing

Mon, 21 Sep 2026 15:16:28 +0000

Spike testing

A spike test verifies whether the system survives and performs under sudden and massive rushes of utilization.

Spike tests are useful when the system may experience events of sudden and massive traffic. Examples of such events include ticket sales (Taylor Swift), product launches (PS5), broadcast ads (Super Bowl), process deadlines (tax declaration), and seasonal sales (Black Friday). Also, spikes in traffic could be caused by more frequent events such as rush hours, a particular task, or a use case.

Spike testing increases to extremely high loads in a very short or non-existent ramp-up time. Usually, it has no plateau period or is very brief, as real users generally do not stick around doing extra steps in these situations. In the same way, the ramp-down is very fast or non-existent, letting the process iterate only once.

This test might include different processes than the previous test types, as spikes often aren’t part of an average day in production. It may also require adding, removing, or modifying processes on the script that were not in the average-load tests.

Occasionally, teams should revamp the system to allow or prioritize resources for the high-demand processes during the event.

Start your learning experience with Grafana Learning Paths

Grafana Learning Paths provide a clear, structured path that leads you from beginner concepts to advanced use cases. Learn about this Grafana feature on Test resilience with k6 spike testing.

Start learning

When to perform a spike test

This test must be executed when the system expects to receive a sudden rush of activity.

When the system expects this type of behavior, the spike test helps identify how the system will behave and if it will survive the sudden rush of load. The load is considerably above the average and might focus on a different set of processes than the other test types.

Considerations

When preparing for a spike test, consider the following:

Focus on key processes in this test type.

Assess whether the spike in traffic triggers the same or different processes from the other test types. Create test logic accordingly.
The test often won’t finish.

Errors are common under these scenarios.
Run, tune, repeat.

When your system is at risk of spike events, the team must run a spikes test and tune the system several times.
Monitor.

Backend monitoring is a must for successful outcomes of this test.

Spike testing in k6

The key differentiators of the spike test are the simulation of sudden and very high loads. It lacks a plateau (full load) duration or is usually brief.

Sometimes, the test may require a load plateau for some time. If a plateau is needed, it’s generally short. A ramp-down can also be quick or unnecessary as the goal is to suddenly increase the system’s load.

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  // Key configurations for spike in this section
  stages: [
    { duration: '2m', target: 2000 }, // fast ramp-up to a high point
    // No plateau
    { duration: '1m', target: 0 }, // quick ramp-down to 0 users
  ],
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
  // MORE STEPS
  // Add only the processes that will be on high demand
  // Step1
  // Step2
  // etc.
};

In a spike test, load quickly increases to an extreme level. The ramp-down period follows when the test reaches the maximum, returning to 0 quickly.

A spike test gets its name from the shape of its load when represented graphically.

Results analysis

Some performance metrics to assess in spike tests include pod speeds, recovery times after the load rush, time to return to normal, or the behavior on crucial system processes during the overload.

Finding how the system responds (if it survives) to the sudden rush helps to optimize it to guarantee that it can perform during a real event. In some events, the load is so high that the whole system may have to be optimized to deal with the key processes. In these cases, repeat the test until the system confidence is high.

Breakpoint testing

Mon, 21 Sep 2026 15:16:28 +0000

Breakpoint testing

Breakpoint testing aims to find system limits. Reasons you might want to know the limits include:

To tune or care for the system’s weak spots to relocate those higher limits at higher levels.
To help plan remediation steps in those cases and prepare for when the system nears those limits.

In other words, knowing where and how a system starts to fail helps prepare for such limits.

A breakpoint ramps to unrealistically high numbers. This test commonly has to be stopped manually or automatically as thresholds start to fail. When these problems appear, the system has reached its limits.

The breakpoint test is another test type with no clear naming consensus. In some testing conversation, it’s also known as capacity, point load, and limit testing.

Start your learning experience with Grafana Learning Paths

Grafana Learning Paths provide a clear, structured path that leads you from beginner concepts to advanced use cases. Learn about this Grafana feature on Find your system’s limits with k6.

Start learning

When to run a breakpoint test

Teams execute a breakpoint test whenever they must know their system’s diverse limits. Some conditions that may warrant a breakpoint test include the following:

The need to know if the system’s load expects to grow continuously
If current resource consumption is considered high
After significant changes to the code-base or infrastructure.

How often to run this test type depends on the risk of reaching the system limits and the number of changes to provision infrastructure components.

Once the breakpoint runs and the system limits have been identified, you can repeat the test after the tuning exercise to validate how it impacted limits. Repeat the test-tune cycle until the team is satisfied.

Considerations

Avoid breakpoint tests in elastic cloud environments.

The elastic environment may grow as the test moves further, finding only the limit of your cloud account bill. If this test runs on a cloud environment, turning off elasticity on all the affected components is strongly recommended.
Increase the load gradually.

A sudden increase may make it difficult to pinpoint why and when the system starts to fail.
System failure could mean different things to different teams

You might want to identify each of the following failure points:
- Degraded performance. The response times increased, and user experience decreased.
- Troublesome performance. The response times get to a point where the user experience severely degrades.
- Timeouts. Processes are failing due to extremely high response times.
- Errors. The system starts responding with HTTP error codes.
- System failure. The system collapsed.
You can repeat this test several times

Repeating after each tuning might let the you push the system further.
Run breakpoints only when the system is known to perform under all other test types.

The breakpoint test might go far if the system performs poorly with the previous testing types.

Breakpoint testing in k6

The breakpoint test is straightforward. Load slowly ramps up to a considerably high level. It has no plateau, ramp-down, or other steps. And it generally fails before reaching the indicated point.

k6 offers two ways to increase the activity: increasing VUs or increasing throughput ( open and closed models). Different from other load test types, which should be stopped when the system degrades to a certain point, breakpoint load increases even as the system starts to degrade. That makes it recommendable to use ramping-arrival-rate for a breakpoint test.

The test keeps increasing load or VUs until it reaches the defined breaking point or system limits, at which point the test stops or is aborted.

import http from 'k6/http';
import { sleep } from 'k6';

export const options = {
  // Key configurations for breakpoint in this section
  executor: 'ramping-arrival-rate', //Assure load increase if the system slows
  stages: [
    { duration: '2h', target: 20000 }, // just slowly ramp-up to a HUGE load
  ],
};

export default () => {
  const urlRes = http.get('https://quickpizza.grafana.com');
  sleep(1);
  // MORE STEPS
  // Here you can have more steps or complex script
  // Step1
  // Step2
  // etc.
};

The test must be stopped before it completes the scheduled execution. You can stop the test manually or with a threshold:

To stop k6 manually in the CLI, press Ctrl+C in Linux or Windows, and Command . in Mac.
To stop the test using a threshold, you must define abortOnFail as true.

For details, refer to Thresholds.

Results analysis

A breakpoint test must cause system failure. The test helps identify the failure points of our system and how the system behaves once it reaches its limits.

Once the system limits are identified, the team has two choices: accept them or tune the system.

If the decision is to accept the limits, the test results help teams prepare and act when the system is nearing such limits.

These actions could be:

Prevent reaching such limits
Grow system resources
Implement corrective actions for the system behavior at its limit
Tune the system to stretch its limits

If the action taken is to tune the system, tune, then repeat the breakpoint test to find where and whether the system limits moved.

A team must determine the number of repetitions of the breakpoint test, how much the system can be tuned, and how far its limits can be tuned after each exercise.