Gatling "Assertion(s) failed" (global responseTime/percentiles) in CI

Gatling evaluates the setUp(...).assertions(...) block after the run and reports "Assertion(s) failed !" with the specific expectation that was not met. It then exits non-zero so the build fails on a performance regression.

What this error means

The console ends with "Assertion(s) failed !" listing an expectation like "global responseTime 95th percentile is less than 500 : false", and the Gatling process returns a non-zero exit code.

Gatling

Assertion(s) failed !
global: responseTime.percentile3 is less than 500.0 : false (actual : 1843)
global: failedRequests.percent is less than 1.0 : false (actual : 4.2)

Common causes

A response-time or failure-rate assertion was breached

The p95/p99 latency or failure percentage exceeded what assertions(global.responseTime...) allows, so the gate fails as designed.

The assertion is tuned for a faster environment

A percentile bound set against production hardware fails against a smaller CI target that is legitimately slower.

How to fix it

Read the failed assertion and fix or retune it

Identify which assertion line ends in "false" and its actual value.
Confirm whether the app regressed or the CI target is undersized.
Fix the slow path, or set the bound to what the CI environment can meet.

LoadSimulation.scala

setUp(scn.injectOpen(rampUsers(100).during(30)))
  .assertions(
    global.responseTime.percentile3.lt(500),
    global.failedRequests.percent.lt(1.0)
  );

Gate the build on the exit code

Let a failed assertion fail the job so a regression cannot merge; do not swallow Gatling's non-zero exit.

.github/workflows/ci.yml

- name: Gatling load test
  run: ./mvnw gatling:test  # non-zero exit on failed assertion fails the job

How to prevent it

Express performance budgets as Gatling assertions so they gate CI.
Calibrate percentile bounds to the environment CI tests.
Do not catch or ignore Gatling's non-zero exit in the pipeline.