One of Gatling's biggest strengths over JMeter is its reports. In JMeter, you need to add Listener elements, and the good HTML reports require the HTML Report Generator plugin or post-processing with JTL files. In Gatling, beautiful, interactive HTML reports are generated automatically after every test run. No configuration, no plugins, no extra steps. You run the test, and the report opens in your browser.
The Gatling report is a single-page HTML file (with embedded charts) that contains everything you need to analyze a test run. It is divided into two main sections: global statistics and per-request details.
Overview: total requests, success/failure counts, min/max/mean/p50/p75/p95/p99 response times, requests per second over time
Active Users Over Time: a chart showing how many virtual users were active at each second -- helps you see the injection profile in action
Response Time Distribution: histogram showing how many requests fell into each response time bucket (0-200ms, 200-500ms, 500-1000ms, 1000ms+)
Response Time Percentiles Over Time: line chart showing p50, p75, p95, p99 as the test progresses -- crucial for spotting degradation under increasing load
Requests Per Second: throughput chart showing how many requests your system handled each second
Responses Per Second: grouped by status code -- see when errors start appearing
Per-Request Statistics: each named request (like "Login", "Search") has its own stats table and charts -- drill down to find the slowest endpoint
Do not just look at the average response time and call it a day. Here is the order I read every Gatling report, and what I look for at each step.
| Step | What to Check | Red Flag |
|---|---|---|
| 1. Success rate | Global success percentage | Below 99% under normal load |
| 2. p95 response time | What 95% of users experienced | Above your SLA threshold (usually 2-3s) |
| 3. p99 response time | What the worst 1% experienced | More than 3x the p95 (tail latency issue) |
| 4. Response time over time | Does it degrade as load increases? | Upward trend = bottleneck hit |
| 5. Errors over time | When do errors start appearing? | Errors clustering at specific user counts |
| 6. Per-request breakdown | Which endpoints are slowest? | One endpoint much slower than others |
| 7. Active users vs response time | Correlation between load and speed | Response time jumps at specific user counts |
# After running a test, Gatling prints the report location:
# Reports generated in 0s.
# Please open the following file:
# /path/to/target/gatling/browsesimulation-20240115120000/index.html
# Open the report
open target/gatling/browsesimulation-20240115120000/index.html # Mac
xdg-open target/gatling/browsesimulation-20240115120000/index.html # Linux
# Archive reports for sharing (it is a self-contained HTML folder)
zip -r load-test-report-sprint42.zip target/gatling/browsesimulation-20240115120000/
# Compare two runs: open both reports side by side
# Look at the same metrics in both and compareWhile the test is running, Gatling prints real-time stats to the console every 5 seconds. This gives you a live view of how the test is going without waiting for the final report.
================================================================================
2024-01-15 12:00:05 30s elapsed
---- Requests ------------------------------------------------------------------
> Global (OK=1250 KO=3 )
> Home Page (OK=500 KO=0 )
> Product List (OK=450 KO=1 )
> Product Detail (OK=300 KO=2 )
---- Browse Products -----------------------------------------------------------
active: 47 / done: 53
================================================================================
---- Global Response Time Distribution -----------------------------------------
> t < 800 ms 1100 ( 88%)
> 800 ms <= t < 1200 ms 120 ( 9%)
> t >= 1200 ms 30 ( 2%)
> failed 3 ( 0%)
================================================================================Gatling reports are static HTML files with no server dependency. You can host them on any web server, attach them to Jira tickets, store them in S3, or commit them to a "test-reports" repository. In CI/CD, many teams archive Gatling reports as build artifacts so they can compare runs across sprints.
Q: How do you analyze Gatling test results? What metrics do you focus on?
A: Gatling generates detailed HTML reports automatically. I analyze them in this order: First, I check the success rate -- anything below 99% under expected load is a problem. Second, I look at p95 and p99 response times, not the average, because averages hide the experience of the slowest users. Third, I check the response time over time chart to see if performance degrades as load increases -- a flat line is good, an upward curve means a bottleneck. Fourth, I look at the per-request breakdown to find which specific endpoints are slow. Finally, I correlate active users with response time to identify at what user count performance starts degrading. For CI/CD, I set assertions so the build fails automatically if p95 exceeds our SLA or success rate drops below 99%.
Key Point: Gatling reports are automatic, beautiful, and self-contained. Read them in order: success rate, p95, p99, degradation over time, per-request breakdown. Archive reports as build artifacts for historical comparison.
Key Point: Reports are automatic and comprehensive -- read success rate first, then percentiles, then degradation patterns