Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/gatling/gatling.io-doc/llms.txt

Use this file to discover all available pages before exploring further.

Gatling Enterprise includes a no-code test builder that lets you create and run load tests entirely through a graphical interface. There is no simulation file to author, no build tool to configure, and no CLI to learn. You define your target URL, describe the user request sequence, choose a load model, optionally set acceptance criteria, and click Save and launch. Results appear in real time on the dashboard. This is the fastest path to discovering how your application behaves under load — and a practical starting point before you graduate to code-based simulations for more complex scenarios.
The no-code GUI builder is a Gatling Enterprise Edition feature. You need an account to use it. Sign up for a free 14-day trial — no credit card required.

Access the No-Code Builder

1

Log In to Gatling Enterprise

Navigate to https://cloud.gatling.io in your web browser. Log in with your credentials, or create an account if you don’t have one yet.
2

Open the No-Code Test Builder

On the Latest test runs pane of the landing page, click Create a No-code test. The builder opens and walks you through four configuration steps:
  1. Set up your scenario
  2. Set up the injection profile
  3. Choose your settings (optional)
  4. Apply acceptance criteria (optional)
You can move freely between steps before launching.

Configure Your Test

1

Set Up Your Scenario

The scenario defines what your virtual users do. Each request represents one user action.
  1. Enter a descriptive name in the Test name field (for example, Product catalog capacity test).
  2. Click the link icon (🔗) to the right of the Request URLs field.
  3. Select an HTTP method from the dropdown (GET, POST, PUT, DELETE, etc.) and enter the full URL.
Example using the Gatling demo API:
MethodURL
GEThttps://api-ecomm.gatling.io/products
The Gatling demo e-commerce API at https://api-ecomm.gatling.io is public and safe to use for practice. The base URL for the API is https://api-ecomm.gatling.io.
To create a multi-step scenario:
  • Click Add request to chain a second (or third) request after the first.
  • Add pauses between requests to simulate the time a real user spends reading a page before taking the next action. Pauses make your load model more realistic.
Start with a single request to verify the test runs correctly, then add more requests to build up a realistic user journey.
2

Set Up the Injection Profile

The injection profile controls how virtual users arrive over the course of the test. Gatling Enterprise provides three built-in test types suited to common performance testing goals:

Capacity Test

Gradually increases load to find the point where your application’s performance degrades. Use this to discover maximum throughput.

Stress Test

Rapidly spikes load to test how your application handles sudden surges in traffic. Use this to simulate unexpected traffic bursts.

Soak Test

Applies steady load over a long duration. Use this to catch memory leaks, connection pool exhaustion, and other time-sensitive degradation.
Example capacity test configuration:
FieldValue
Test typeCapacity test
Total test duration90 seconds
Initial user arrival rate1 user/second
Final user arrival rate10 users/second
Gatling will linearly ramp the arrival rate from 1 to 10 users per second over 90 seconds, giving you a clear picture of how performance evolves as load increases.
3

Choose Your Settings (Optional)

Configure team ownership and the geographic origin of your synthetic traffic:
  1. Select the team that owns this test (usually default for single-team accounts).
  2. Under Configure your locations, click the arrow to open the dropdown and select a load generator location.
The Gatling demo API is hosted near Paris. Selecting a European location typically produces the lowest base latency for demo tests. For testing your own application, choose a location that reflects where your real users are located.
4

Apply Acceptance Criteria (Optional)

Acceptance criteria (also called Assertions) let you define pass/fail thresholds for the test. When a threshold is breached, the test is marked as failed — useful for CI/CD integration and automated performance gates.Example thresholds:
CriterionToggleValue
Global 95th percentile response time✅ Enabled250 ms
Global success ratio✅ Enabled99%
To configure these:
  1. Enable the Global 95th percentile on response time should be lower than toggle.
  2. Enter 0.25 in the input field (units are seconds).
  3. Enable the Global success ratio to be higher than toggle.
  4. Enter 99 in the input field.
Acceptance criteria are evaluated at the end of the test run. Results are visible in the Report tab and can be consumed programmatically via the Gatling Enterprise API for CI/CD pipelines.
5

Launch the Test

Click Save and launch to start your load test. Gatling Enterprise provisions load generators in your selected location and begins sending requests immediately.The dashboard updates in real time, showing:
  • Active virtual users over time
  • Requests per second (throughput)
  • Response time percentiles (50th, 75th, 95th, 99th)
  • Success/failure rates per request
When the test completes, navigate to the Report tab for the full results breakdown, including:
  • Response time percentile distributions
  • DNS resolution times
  • Connection establishment times
  • Per-request statistics table

Edit and Iterate

After reviewing your results, click Edit test to adjust the configuration and re-run. Common iteration patterns:

Increase Load

Raise the final user arrival rate to push beyond the throughput you’ve already validated. Look for the inflection point where latency starts to climb.

Add More Requests

Extend the scenario with additional API endpoints to simulate a complete user journey — login, browse, add to cart, checkout.

Tighten Acceptance Criteria

Once your application meets a loose threshold, tighten it to establish stricter performance guarantees.

Export to Code

The no-code builder can export your test as a Java/Maven project. This gives you a starting point for advanced customization with feeders, checks, and complex injection profiles.

Limits and Considerations

The no-code GUI builder is exclusive to Gatling Enterprise Edition. Locally executed (Community Edition) simulations require a code-based approach using the Java, Kotlin, Scala, or JavaScript SDKs.
For tests that require dynamic data, correlation of session tokens, conditional logic, or multi-step authentication flows, you will need a code-based simulation. The no-code builder is designed for straightforward HTTP scenarios — it is the right starting point, but not the ceiling of what Gatling can do.

Next Steps

Write Code Simulations

Graduate to code-based simulations for dynamic data, authentication flows, feeders, and complex injection models.

Low-Code Tools

Import a Postman collection or record a browser session to generate a simulation automatically.

Build docs developers (and LLMs) love