Level 1
One script, one engineer
A simulation in the app repo, run from a laptop before a launch. It works, and it costs nothing to keep.
+ One simulation
YOU BUILT YOUR OWN LOAD TESTING PLATFORM.
Nobody plans to. It happens one reasonable decision at a time, and every new team and every new test adds something to maintain.
Follow the complexity journey, then find where your own suite sits on it.
The complexity journey
MORE TEAMS, MORE TESTS, MORE TO MAINTAIN.
Every load testing setup ends up maintaining three layers: the tests, the infrastructure that runs them (including the network paths that infrastructure needs), and the results you read afterwards. Here’s how each one grows, level by level, as more people run more tests on a platform you built yourself.
LEVEL 1
TestsInfrastructureResults
One engineerMany teams
What you maintain now
Which level is your team at?
Describe your setup to get your level, what to fix first, and a CI pipeline to copy. Or see Gatling Enterprise live.
Levels 1 to 7: the suite spreads to more teams
Level 2
The test can’t reach staging
Staging sits on an internal network. The laptop that ran the first script has no route to it, so before anything else, someone has to find a machine that does.
+ A machine inside the network
Level 3
A second team copies the scripts
Another team needs load tests. Copying the first suite is faster than sharing it, so now every request exists twice.
+ A forked copy of the suite
Level 4
Injectors saturate. You add machines.
Peak tests outgrow one machine. You add injectors, then a script to start them at the same time.
+ Injector machines, start-up scripts
Level 5
Security asks for fixed IPs to allowlist
The API gateway only accepts traffic from approved source IPs. Each new injector needs a firewall ticket, and cloud machines with changing IPs can’t be used at all.
+ IP allowlist and firewall tickets
Level 6
You script a dashboard to merge results
Each injector writes its own report. Someone writes a job to merge them, then a dashboard to read the result.
+ Merge job and dashboard
Level 7
An API change breaks half the tests
One endpoint changes, and every copied request that calls it breaks. Fixing it means finding each copy.
+ Duplicated requests
Levels 8 to 10: a platform appears
Level 8
Wiring every pipeline to CI by hand
Shared CI runners aren’t allowed on the internal network. Each team sets up self-hosted runners, then wires its pipeline, environments and secrets by hand.
+ Self-hosted CI runners, per-team CI jobs
Level 9
Multi-region means a new cloud setup
Users abroad need testing from closer to them. That’s another cloud account, network rules and machine images to keep in sync.
+ Regional cloud setup
Level 10
Nobody can compare this run with last quarter
Reports sit in CI artifacts and old folders. A regression shows up, and nobody can say which release introduced it.
+ Report archive
Levels 11 to 13: running the platform becomes the job
Level 11
Security asks who can load test production
Anyone with the scripts can point them at production. Now there’s an access review, and tokens to rotate.
+ Access rules and tokens
Level 12
The engineer who built it all leaves
The start-up scripts, the merge job and the dashboard were one person’s side project. The documentation is the code.
+ Tooling only one person knew
Level 13
More time on the tool than on the tests
Each release needs the tooling fixed before the tests can run. The tests themselves have barely changed.
+ Upkeep before every release
Where this leaves you
Look at what you maintain by the last level. Almost none of it is test code. It’s machines, network routes, allowlists, scripts, archives and access rules, and it keeps growing whether or not your tests do.
Then it depends on your industry
EVERYONE HITS THE SAME FIRST WALLS. THEN IT GETS SPECIFIC.
The first levels look alike in every company. Further up, each industry has its own hard part, and it’s rarely the user journey.
In finance, it’s the network
In banks, payment companies and insurers, the user journey is rarely the hard part. The harder questions are about the network:
- Where are tests allowed to run?
- How does traffic reach internal systems?
- Are CI runners allowed on the network at all?
- Do you need private routing, IP allowlisting, or load generators inside your own network?
NICKEL4.5M+payment accounts
A BNP Paribas payment account provider.
It runs its Gatling load generators inside its own on-prem environment through private locations, a security and compliance requirement in banking.
“Three years ago, releasing our core banking system meant days of stress.
Today, deployments are stable and invisible to our users.”
AIDENAIUp to 30%faster responses across client builds
Builds apps for major insurers and banks.
It got through a Singapore client’s strict firewall rules by running a region-specific load generator with a dedicated IP.
“The ability to simulate loads from specific geographies and share testing workflows across our team has made Gatling a core part of our delivery lifecycle.”
In retail, it’s the shape of the peak
Everyone knows the checkout flow. What breaks is the minute a sale opens:
- Can you reproduce thousands of shoppers checking out in the same minute?
- Does autoscaling react before the burst, or after it?
- Does the test mix match real traffic, page type by page type?
TAPE À L’ŒIL8 AMlaunch-day checkout rush
Shoppers fill their carts ahead of big sales, then check out together the moment the sale opens.
The team now runs warm-up tests so pods scale before the real load hits.
“Before Gatling, going live felt like crossing our fingers and hoping it held.
Now we can simulate, measure, and move forward with clarity.”
In SaaS, it’s the coordination work
Product teams write their own tests. The work nobody owns is everything around them:
- Who provisions the runners, and who tears them down?
- Who merges results from every generator into one view?
- How do tests reach internal staging that isn’t public?
ATTENTIVE10x+Black Friday message traffic
Before Gatling Enterprise, the team maintained its own coordination layer: provisioning runners, teardown, and merging results by hand.
It now generates load from inside its own network through private locations.
“We had to create and maintain our own infrastructure to run JMeter and ghz.
With Enterprise, that’s handled for us, which saves a lot of engineering time.”
In telecom, it’s where the load comes from
Millions of devices connect at once, and latency depends on the path traffic takes:
- Can you open hundreds of thousands of concurrent connections?
- Which region does the load come from, and which gateway does it hit?
- Is the latency you measure the application’s, or the network path’s?
BOUYGUES TELECOM<100msinternal latency at 100,000 concurrent requests
Its Paris API gateway couldn’t absorb the traffic, while the Ireland region handled it with extra latency.
Placing load generators close to the application fixed the measurement and the bottleneck.
“Gatling Enterprise Edition allowed us to simulate extremely high traffic without overloading our infrastructure. It quickly became an indispensable part of our development pipeline.”
In logistics, it’s the length of the cycle
A parcel’s journey takes days, and some problems only appear over days:
- Can a test run as long as your real business cycle?
- Can you compare this week’s long run with the last one?
- Do your tests cover the event-driven protocols, not just HTTP?
INPOST5 daysone continuous simulation
The test followed the full parcel journey, from purchase to locker pickup.
It exposed bottlenecks that short runs missed, from database indexing to the physical connectors between servers and storage.
“With autoscaled generators we stopped maintaining boxes.
We likely saved FTEs.”
In media, it’s testing in production
When staging doesn’t behave like production, the only realistic test is the live platform:
- How do you raise load on production without hurting live viewers?
- Can you reproduce millions of users arriving in seconds?
- Which third-party service gives way first?
JIOSTAR7–8Mconcurrent users within 90 seconds
That’s what key IPL moments look like.
Under that surge, SMS OTP providers were the first to buckle.
“Gatling Enterprise’s ease of use and real-time monitoring significantly reduced our testing cycle time and infrastructure costs.”
CANAL+Livetested in production
Its environments don’t mirror production, so it tests the live platform in progressive steps, each one informing the next.
Read the Canal+ storyGatling Enterprise
OR LET THE PLATFORM CARRY IT.
Look back at what the journey added. Most of it is infrastructure, network and results work, not test code. Gatling Enterprise keeps your tests as code in your repo and carries the rest, so the curve stays flat as you grow.
You build and maintain
Gatling Enterprise carries
Tests
Copied suites, shared requests, CI wiring for every pipeline
Tests as code, built from Git, created and updated with AI
Infrastructure
Injector machines, network routes, IP allowlists, CI runners, regions and upgrades
Managed or private locations, dedicated IPs for allowlisting, generator health on every run
Results
Merge jobs, dashboards, report archives and baselines
History, trends, SLOs and AI analysis on every run
Tests stay yours either way. Scripts written for the open-source framework run unchanged on Gatling Enterprise.
“Reliability is not an option. It’s a feature.”
Chaitanya Bhatt, Principal Engineer, Intuit
Your turn
Find your level on the complexity curve.
Describe your load tests, where they run and how you read the results. You’ll get your level on the curve, what to fix first, and a repo layout and CI pipeline you can copy.
Find your levelLive session
See Gatling in action.
Build, run, and interpret your first load test. A practical session: by the end, you’ll know exactly what Enterprise gives you out of the box.
Register for the next live session