What I like most about Gatling is the flexibility and freedom it gives you when designing performance tests. It makes it easy to create reusable scenarios, build complex test chains, and structure tests in a maintainable way.

The ability to use a real programming language such as Kotlin is a major advantage, as it allows for advanced logic and customization that would be difficult to achieve with more restrictive tools. This gives me full control over how I design, organize, and execute my tests.

I also appreciate how clear and intuitive the reporting is. The reports are easy to understand and communicate to both technical and non-technical stakeholders. Overall, the coding-first approach and the level of control it provides are what make Gatling stand out for me. Review collected by and hosted on G2.com.

One area where Gatling could improve is troubleshooting and error analysis. The reports do not always provide enough detail about failed requests, which can make investigations more difficult. For example, when a request returns an HTTP 500 error, it would be helpful to see the underlying error message or stack trace directly in the report instead of having to search through application logs. Having more detailed failure information available out of the box would make debugging and root-cause analysis much faster and more efficient. Review collected by and hosted on G2.com.

I like the documentation and the many languages it supports; it gives me flexibility across multiple projects. Review collected by and hosted on G2.com.

It’s hard to think of something I dislike, but if I had to mention one thing, it would be that the generated reports could be more user-friendly and easier for anyone to understand at first sight. Review collected by and hosted on G2.com.

I found Gatling easy to understand and write code in. Even when I joined the project without knowing anything about Gatling, the inbuilt repository with the code and framework was easy to comprehend. The code is in a very readable format, so anyone with some technical knowledge can read, understand, and write it. The documentation on the Gatling site is pretty self-explanatory, making it straightforward to learn anything new and implement Gatling code in services. Working with Gatling was really good because of this easy-to-read and follow documentation. The initial setup was also easy, with top-notch documentation that anyone can follow. Review collected by and hosted on G2.com.

Not anything to say at this stage Review collected by and hosted on G2.com.

I like Gatling for its usability and simplicity compared to other tools like JMeter. The multithreading and automation capabilities are particularly beneficial, allowing me to set up each thread with ease and perform a lot of actions. It was great for handling load testing without being overly complicated, which made tasks much easier to manage. The initial setup was quite easy and took less than a day. Review collected by and hosted on G2.com.

I don't think Gatling was able to run on the server as a watchdog or for deploying tests for stress and load testing. Also, I don't remember if Gatling had the option to run load tests while deploying on CICD. Review collected by and hosted on G2.com.

The ability to customize the validations and the ability to integrate as a DSL in different programming languages. The broad community is fundamental when it comes to select it since you can find solutions to most of challanges from people in the past already. Review collected by and hosted on G2.com.

The HTML report is hard to modify; we have to depend on a cloud solution, which, for a small project, is not feasible. Review collected by and hosted on G2.com.

Flexibility. I like to write in Scala, others prefer Kotlin, Frontend and QA colleagues prefer TypeScript or Javascript. All as code, all in cloud. Perfect setup for current times Review collected by and hosted on G2.com.

Setting up the internal network runners is not ideal, but nothing overcomplicated Review collected by and hosted on G2.com.

In my QA role, I relied heavily on Gatling to stress-test our core vehicle-booking flows. The standout feature for me was Gatling’s code-as-configuration DSL. Since we could write load tests as code, we kept them in version control right alongside the application code. That shift changed our workflow significantly and saved our QA team hours of manual test maintenance each week, especially compared with UI-heavy legacy tools.

Another benefit I didn’t expect at first was how smoothly Gatling fit into our existing CI/CD pipelines. It didn’t just enable large, concurrent stress tests; it also gave us immediate, automated performance feedback on new deployments. On top of that, the out-of-the-box HTML reporting is excellent—it helped us quickly pinpoint specific database bottlenecks during high-traffic booking simulations without needing to set up external visualization dashboards. Review collected by and hosted on G2.com.

While the code-as-configuration approach is a strength, the steep learning curve of Gatling's Scala-based DSL was our biggest hurdle. During our Europcar booking stress tests, onboarding QA engineers who were used to visual, GUI-based tools (like JMeter) took significantly longer. The impact was a slower initial setup phase for our load-testing framework, as team members had to learn a new language syntax just to write basic tests. A potential improvement would be offering a lightweight, visual test-builder interface for simpler scenarios, which would lower the barrier to entry while keeping the powerful code DSL for complex edge cases. Review collected by and hosted on G2.com.

Gatling has been easy to integrate into our Jenkins pipeline, making performance testing an automated part of our release process. I also like the detailed reports, which make it simple to analyze response times and identify bottlenecks. The scripting approach gives us flexibility to maintain and update test scenarios as our application evolves, and overall it has been a reliable tool for our performance testing needs. Review collected by and hosted on G2.com.

The initial learning curve is probably the biggest drawback, especially for team members who are new to Gatling's scripting approach. Creating and maintaining complex test scenarios can take some time to get used to. While the documentation is helpful, I'd appreciate more real-world examples and troubleshooting guides for advanced use cases. Apart from that, the tool has been reliable for our performance testing needs. Review collected by and hosted on G2.com.

I was able to handle performance testing at scale while keeping the test scripts clean and maintainable.

The developer friendly method using code based scenarios made it easier to version, review, and collaborate on tests compared to GUI tools. Review collected by and hosted on G2.com.

We need more beginner friendly documentation, examples, that would make it more accessible for new users.

There can be a learning curve for users who are more familiar with traditional GUI based performance testing tools Review collected by and hosted on G2.com.

I like that Gatling is a non-GUI, developer-centric tool. The fact that scripts can even be AI-generated is pretty cool, and I find the memory footprint per script to be actually minuscule. It's efficient enough that I can use a single VM to run over 500 threads. I also appreciate how Gatling can be integrated into our dev workflows, allowing Claude to auto-generate Gatling scripts as we develop and build APIs. Additionally, AI can go through Postman collections to create a complete Gatling suite of scripts. Setting up Gatling was rather easy, with no problems there. Review collected by and hosted on G2.com.

Since Gatling is non-GUI, I find it has a learning curve for us non-developers. It takes time for us to figure out the functions and features. Also, I face challenges because Gatling requires Scala, and I had to cross-train Java developers to read and understand Scala code. Review collected by and hosted on G2.com.