Limiting HTML report generation with Gatling’s --no-reports flag

Short answer

--no-reports only skips the post-run HTML report generation step. It does not change what is recorded during the run. The raw simulation.log in the results directory is still written with the same level of detail as a normal run, because that log is the input the report generator would have parsed. If your concern is data leakage, the flag alone is not a sanitization mechanism.

What the flag does and doesn’t do

Gatling’s run has two phases: the load phase, where data writers record events, and the reporting phase, where the file writer’s output is turned into the HTML report under the results folder. --no-reports disables only the second phase. So after a run with the flag you should expect:

• No index.html and no generated report assets in the results directory.
• simulation.log still present, containing the same scenario, request, response-status and timing records it would contain otherwise.

Stored request/response bodies are a separate concern. Gatling does not dump payloads into simulation.log by default. Bodies only appear when you explicitly enable debugging hooks — for example, an extraInfoExtractor on the HTTP protocol, or verbose HTTP logging for the io.gatling.http logger in logback. Those hooks feed the same log/output channels regardless of whether reports are generated, so --no-reports has no effect on them.

If you need to guarantee nothing sensitive persists

The reliable lever is the data writer configuration, not the report flag. In gatling.conf, remove the file writer:

gatling.data.writers = [console]

With no file writer, no simulation.log is created at all, so there is no on-disk artifact to leak. The trade-off is real: you lose the ability to regenerate a report offline later. A middle path is to keep the file writer, run with --no-reports, and delete the results directory in your CI pipeline after extracting whatever metrics you need.

Also audit your logging setup separately: confirm extraInfoExtractor is not unconditionally capturing bodies, and that the logback level for Gatling’s HTTP packages is not DEBUG/TRACE in the environment you’re worried about. That is where payload leakage actually comes from — not the HTML report.

Verify it yourself

1. Run a short simulation with --no-reports and inspect the results directory: confirm index.html is absent but simulation.log exists.
2. Force a failing request and grep the log and console output for any body content, to confirm your logging config isn’t capturing payloads.
3. Set gatling.data.writers = [console], rerun, and confirm no simulation.log is written.

Caveats

Exact flag names and config keys vary across Gatling 3.x versions and between the OSS bundle, the Maven/Gradle plugins, and Enterprise/FrontLine launchers — check the documentation for the version you deploy. Older versions also logged more HTTP detail on failures by default, so behavior you remember from an older setup may not match a current one.