Writing Gatling simulations from scratch is fine when you know the API endpoints. But for complex web applications with dozens of pages and AJAX calls, manually writing every request is tedious and error-prone. The Gatling Recorder solves this -- it acts as a proxy between your browser and the server, captures every HTTP request, and generates a Gatling simulation file automatically. Think of it as JMeter's HTTP(S) Test Script Recorder, but for Gatling.
Start the Recorder: run bin/recorder.sh (standalone) or use the Maven/Gradle recorder task
Configure the Recorder: set the listening port (default 8000), choose output format (Java or Scala), set the package and class name
Configure your browser: set HTTP proxy to localhost:8000, and HTTPS proxy to localhost:8000
Click Start in the Recorder window
Browse your application in the browser -- perform the user journey you want to test
Click Stop in the Recorder when done
The Recorder generates a simulation file in your project's source directory
# Standalone bundle
./bin/recorder.sh
# Maven project
mvn gatling:recorder
# Gradle project
gradle gatlingRecorderIf setting up a proxy is inconvenient, there is an easier option. Modern browsers can export HTTP traffic as HAR (HTTP Archive) files. Record your browser session using DevTools, export the HAR file, and import it into the Gatling Recorder. No proxy configuration needed.
Open Chrome DevTools (F12) and go to the Network tab
Browse your application and perform the user flow
Right-click in the Network tab and select "Save all as HAR with content"
Open the Gatling Recorder and switch to "HAR Converter" mode
Select the saved HAR file and click Convert
The Recorder generates a Gatling simulation from the HAR file
Raw recorded scripts are messy -- they include every CSS file, every image, every analytics request, every tracking pixel. You need to clean them up before using them as load tests.
Never use a recorded script as-is for load testing. It contains your personal session tokens, hardcoded data, and unnecessary requests. A recorded script is a starting point -- always clean it up, parameterize it, and add checks before running it as a performance test.
Key Point: The Recorder (proxy or HAR import) captures browser traffic and generates simulation code. Always clean up recorded scripts: remove noise, add names, parameterize data, and add checks.
Key Point: Use the Recorder for complex flows, but always clean up the generated code -- it is a starting point, not a finished test