Gatling Assertions and Reports

Gatling’s assertions, defined at the simulation level, serve the same CI-gating purpose as k6’s thresholds — aggregate pass/fail criteria evaluated after a run, causing Gatling itself to report a non-zero exit code on violation.

Defining assertions

setUp(scn.inject(rampUsers(100).during(30.seconds)))
  .protocols(httpProtocol)
  .assertions(
    global.responseTime.percentile(95).lt(300),
    global.responseTime.percentile(99).lt(800),
    global.failedRequests.percent.lt(1),
    details("Search").responseTime.percentile(95).lt(200)
  )

global assertions apply across the whole simulation; details("name") scopes an assertion to a specific named request, similar to k6’s per-scenario/tagged thresholds — letting different parts of a test carry different latency budgets.

Why percentile-based assertions are the default mental model here too

Gatling’s assertion API is built around percentiles and rates from the start (percentile(95), failedRequests.percent), reinforcing the same principle covered throughout this site: meaningful performance criteria are expressed in percentile and rate terms, not raw averages — Gatling’s API design effectively nudges users toward this regardless of whether they’ve internalized why it matters.

The generated HTML report

Gatling automatically produces a detailed, self-contained HTML report after every run without extra flags — global stats, percentile breakdowns, requests-per-second over time, and a response time distribution chart, broadly comparable to JMeter’s -e -o output or k6’s summary, generated by default rather than as an opt-in step.

Reading the response time distribution chart

Gatling’s report includes a response time range distribution (count of requests falling into response time buckets: under 800ms, 800ms-1.2s, etc.) — a quick way to visually spot a bimodal distribution (a cluster of fast requests and a separate cluster of slow ones) that a single percentile number wouldn’t reveal on its own, the same diagnostic value covered in this site’s article on JMeter results analysis.

CI integration

Because assertion results determine Gatling’s exit code directly, CI integration follows the same simple pattern as k6: run the simulation, check the exit code — no custom result-parsing script needed, the same practical CI-friendliness advantage k6 has over JMeter’s default behavior.

Comparing runs over time

Gatling’s open-source report doesn’t natively diff across separate runs the way some commercial reporting add-ons (or Gatling Enterprise, the commercial offering) do — for trend tracking across many CI runs over time, either adopt Gatling Enterprise’s reporting, or pipe Gatling’s results into your own time-series store (the same general pattern recommended for k6 and JMeter when native tooling doesn’t cover longitudinal trend analysis).

Takeaway: Gatling’s assertions and default HTML report both default to percentile-based thinking, which aligns naturally with how performance SLOs should actually be defined — one of the quieter but genuinely useful aspects of the tool’s design.