Help build the future of open source observability software Open positions

Check out the open source projects we support Downloads

The actually useful free plan

Grafana Cloud Free Tier
check

10k series Prometheus metrics

check

50GB logs, 50GB traces, 50GB profiles

check

500VUk k6 testing

check

20+ Enterprise data source plugins

check

100+ pre-built solutions

Featured webinar

Getting started with grafana LGTM stack

Getting started with managing your metrics, logs, and traces using Grafana

Learn how to unify, correlate, and visualize data with dashboards using Grafana.

Performance testing best practices: How to prepare for peak demand with Grafana Cloud k6

Performance testing best practices: How to prepare for peak demand with Grafana Cloud k6

2025-11-12 9 min

For many organizations, periods of high customer activity are anything but relaxing. Events like Black Friday, product launches, or major sales can put intense strain on the software and infrastructure systems that support a company’s web applications. Without proactive performance testing, these moments can quickly turn into poor user experiences and lost revenue.

To prepare for these peak loads, companies like Just Eat Takeaway.com — a leading Amsterdam-based online food delivery company, operating popular brands such as Just Eat, Takeaway.com, Lieferando, and SkipTheDishes — use Grafana Cloud k6, the fully managed performance testing platform powered by Grafana k6 OSS.

Haven’t tried performance testing in Grafana Cloud yet? Sign up for a free account today.

“In 2024 alone, we took over half a billion orders,” said Christopher Orchard, Senior Site Reliability Engineer at Just Eat Takeaway.com, at ObservabilityCON 2025. “We are in 17 countries, but within the countries, we are then split across another 15 different time zones. So throughout the day we are processing thousands and thousands of orders. Uptime, for us, is key and ensuring we can handle peak-level load throughout the day is critical.”

In this blog post, I’ll share five best practices for performance testing with Grafana Cloud to verify and feel confident in system reliability under load. Spoiler alert: it’s all about testing early and often.

1. Prepare well ahead of time

Like any form of testing, it’s important to set aside ample time for tests to run their course. Crucially, this also means adding contingency planning to account for the time it might take to resolve issues and verify fixes. Given the many ways in which performance issues can manifest, estimating how much time it would take to resolve them is not an exact science. This makes it important to test early. 

“This, for us, is critical,” said Orchard. “We want to shift left as much as possible to catch issues as early as possible.”

Beyond maximizing the amount of time available, testing at the earliest opportunity also means the underlying code is still fresh in the minds of those responsible for it. Making changes to this code may also be easier when no other components depend on it yet.

For the site reliability team at Just Eat Takeaway.com, being able to drive a more flexible and proactive performance testing strategy has been a key advantage of using Grafana Cloud k6.

“Teams can run scheduled tests to get continuous feedback on how their applications are performing with change and with wider platform change. And teams can run on-demand tests,” Orchard said. “If they’ve made a change and need to validate performance, they can do exactly that.”

2. Prioritize the most critical user journeys

Depending on the nature of the application, users might follow different paths or workflows, and it’s not always feasible to test each one. When testing, especially for a high-traffic event, prioritize business-critical user flows, such as those with a direct impact on revenue.

For example, in e-commerce, an obvious example would be the cart checkout. If users need to register or log in to an existing account as part of the checkout process, this functionality should also be treated with high priority.

If you are just beginning your performance testing journey, there are several types of tests you can run that don’t require much upfront effort to develop. Even the simplest of tests, such as throwing GET requests at a homepage, can help uncover unexpected issues. If these tests don’t fully simulate the traffic real users would generate, you can still use the metrics they produce as data points to compare subsequent, more complex tests against.

Once you have identified the flows you want to test, the next step is to create k6 scripts. For some teams, this is a challenging part of the performance testing process, as you are, in effect, reverse-engineering HTTP exchanges that can be incredibly complex. From the many years I’ve spent writing scripts and running load tests, I’ve noticed there is often a relationship between scripting difficulty and server-side performance; if the scripting itself is complex, there’s elevated risk that the server-side will struggle with processing this complexity as well.

To help alleviate the difficulty of scripting, we launched k6 Studio, an open source desktop application that helps you create k6 test scripts quickly and easily via a visual interface.

A screenshot of k6 Studio showing API requests and responses, including GET requests and JSON responses, with detailed headers and parameters.

You can use k6 Studio to:

  • Record a user flow from browser interactions and generate a HAR file.
  • Generate and customize a k6 test script from a HAR file, and use rules to quickly iterate on the script creation process.
  • Test and debug k6 scripts using a visual interface. 

To learn more about k6 Studio, and how to get started, check out our documentation.

3. Be proactive about monitoring 

Modern web applications give developers far more flexibility to deploy code changes than the old days of rich clients, but this agility also increases the risk of performance regressions. And the sooner those regressions are found, the easier (and cheaper) they usually are to fix.

Synthetic monitoring helps with this by automating the running of scripts that proactively monitor the vital signs of an application. These scripts are typically designed to interact with the same APIs or endpoints that a real user would.

With Grafana Cloud Synthetic Monitoring, you can set up a variety of checks — including ping, DNS, HTTP, TCP, and, most recently, browser — to interact with your application on a regular cadence. 

A Grafana Cloud Synthetic Monitoring dashboard displaying a user journey analysis with metrics like success rate and response time.

This offers insights into application uptime, availability, and performance over time. Even though synthetics checks run as a single user, any noticeable increase in response times is a good indication that those delays would only become exacerbated under load.

You can also reuse your k6 scripts for browser and scripted checks in Synthetic Monitoring as performance tests in Grafana Cloud k6. This portability streamlines your workflow and makes it easier to scale your testing strategy across use cases.

4. Always look for patterns

A lot of useful information can be gleaned from patterns that emerge in testing data. The patterns can help explain (or warrant further explanation of) aspects of the system that you might not have previously understood.

Here are some examples I’ve come across over the years:

  • HTTP timeouts: k6 has a default request timeout of 60 seconds. However, timeouts can also happen on the server side. When that’s the case, it can be difficult to determine what on the server side is timing out — for example, was it the web server or some other downstream service? This might not always be obvious with limited access to server-side telemetry, and there’s no guarantee that the server-side sends back a meaningful response that implicates the responsible service. In this situation, the time it took for these requests to eventually time out becomes useful information to potentially narrow down the culprit, as different services likely have different timeout values.
  • Certain patterns only emerge between tests: Even if a test runs successfully, run it again at least once to make sure there is consistency in the reported response times. If response times are even slightly higher in subsequent tests, it could suggest a memory leak. Or, if the test was creating database records, it could be indicative of a missing table index. Whatever the problem may be, this kind of symptom has the potential to cause havoc if not detected.

If your tests encountered a performance issue only part-way through the test, run it again: did the issue appear at the same point in time? If so, that could be indicative of a problem that only manifests under a certain amount of concurrent use of the system.

With performance testing in Grafana Cloud, you can configure a trending metric, which can be used to compare the given metric’s value across runs of the same test.

A Grafana Cloud k6 dashboard displaying performance metrics with a dropdown menu for selecting trending metrics like HTTP Response Time and HTTP Failure Rate.

More recently, we’ve also made it possible to query metrics across test runs using the grafanacloud-k6 data source. This means you can now set up a custom dashboard (more on that below) to display trend information beyond what is provided in the out-of-the-box experience. For example, you could configure trends on a per-scenario basis, or show the trends for response times, request rates, and error rates all on the same screen.

5. Customize your experience

Grafana Cloud k6 provides out-of-the-box dashboards to visualize load and performance test results as the test runs. These dashboards help you quickly interpret results, spot problems, and minimize user impact. 

A Grafana Cloud k6 dashboard showing server performance metrics, including requests, failures, response time, and throughput.

“Out of the box, we get a lot of very useful features,” Orchard said at ObservabilityCON. “We get curated dashboards with extensive test run information… and if you need to dig deeper into exactly how an individual request or endpoint is performed, you can do exactly that.”

To give users even more flexibility, Grafana Cloud k6 ships with a data source that you can query the same way you would other Grafana data sources. This allows you to create a more custom Grafana Cloud dashboard for k6 metrics, with more control over things like panel placement, coloring, and pagination.

More importantly, you can also pull in telemetry from other data sources. Think server logs, CPU/memory statistics, and more, all automatically synchronized to the same time range. This makes it possible to correlate between events on the client-side and happenings on the server-side for faster troubleshooting. 

To fully realize the benefit of custom dashboards, set up dashboard variables to select between different test runs, regardless of which projects or tests they reside within. The end result? A highly-customizable, re-usable dashboard with all the relevant information in the same place.

Wrapping up

Whether you’re preparing for Black Friday, a major product launch, or some other peak seasonality event, the key is to test system reliability early and often — ideally throughout the year. By being proactive, you can catch issues early and ensure an optimal end-user experience.

Grafana Labs was recently named both a Leader and an Outperformer in the 2025 GigaOm Radar Report for Cloud Performance Testing. The report recognizes Grafana Cloud k6 for its strong innovation, comprehensive platform capabilities, and ability to help organizations continuously validate performance and reliability across the entire software delivery lifecycle.

To learn more and get started, please check out our technical docs. Happy testing!

Grafana Cloud is the easiest way to get started with Grafana k6 and performance testing. We have a generous forever-free tier and plans for every use case. Sign up for free now!