Can a Gatling run decide pass or fail on its own in a CI pipeline, and at what point in the run is that verdict computed?

A load generator earns its place in a pipeline by answering one question without help: did this run pass? Gatling answers it natively, and the shape of that answer — when it is computed and what it is computed over — is more important than the fact that it exists. ## How the verdict is declared The pass rule is attached to the same `setUp` call that registers the load profile, so the criteria live in the simulation source next to the load they judge: ```kotlin setUp(browse.injectOpen(atOnceUsers(1))) .assertions( global().responseTime().percentile3().lt(800), global().successfulRequests().percent().gt(99.0) ) ``` Each assertion is a chain that picks a **scope**, a **statistic**, a **metric** and a **condition**. The documentation states the timing without ambiguity: all assertions are evaluated after running the simulation, and if at least one fails, the simulation fails. ## What the process exits with Gatling's launcher defines exactly three status codes: | Code | Meaning | |---|---| | `0` | success — either every assertion passed, or none were declared | | `1` | invalid command line arguments — and, in practice, any crash | | `2` | assertions failed | Only `2` is exhaustive. Gatling logs `Run crashed` and rethrows rather than returning a status code, so a failure in configuration loading, in the simulation's constructor or during the run itself escapes `main` and the JVM terminates on an uncaught exception — which is also exit 1. Read `1` as "the process failed before producing a verdict" rather than as "the simulation never started"; only the log tells you which. That distinction is worth carrying into a pipeline. A job that treats "non-zero" as "performance regression" will report a mistyped flag, or a crashed run, as a failed load test. A job that reads `2` specifically knows the run executed and was judged unsatisfactory. The other half of the contract is the silent case. **A simulation that declares no assertions exits 0.** It did not pass; it simply never judged anything. A pipeline stage that runs a simulation with no `assertions(...)` chain is green by construction and proves nothing, and that is a real failure mode because the run still produces a report full of numbers that look like evidence. ## The consequence of judging after the run Because the whole gate is a post-run computation over consolidated statistics, three things follow: 1. **The pass rule cannot stop a run.** A simulation that is failing its latency target from the first minute still runs to the end of its profile. Bounding the wall-clock cost of a bad run is a separate concern from the pass rule, handled by the run's own duration limits rather than by the assertions. 2. **The verdict is over the whole run.** Statistics are consolidated across everything the run recorded, so a warm-up segment or a deliberate overload tail is inside the numbers being judged unless the simulation was designed to keep them out. Deciding what a pass rule should assert, and over which window, is performance-testing judgement rather than a Gatling feature. 3. **There is exactly one verdict per run.** One process, one exit status. If a profile is executed on several machines, each machine judges only what it saw and produces its own status. ## Where this sits among the alternatives This is one of the differences that actually decides a tool choice, so state it at the right altitude. Load generators differ on **whether** they carry a gate at all and on **when** they evaluate it: * Gatling declares the gate inside the simulation and evaluates it once, after the run, producing a dedicated exit status. No extra tooling is required for a pipeline to fail on it. * Some generators evaluate their criteria continuously as the run proceeds, which lets a breach abort a run early, at the cost of a verdict that depends on when it was checked. * Some generators ship no native gate at all, so a pipeline must score the results file itself with a separate step and own the correctness of that step. Name the contrast; do not borrow the numbers. Another tool's non-zero exit code is its own, and assuming Gatling shares it is a small mistake that produces a pipeline which silently never fails. ## Answering it well The complete answer is three clauses: the gate is declared on `setUp` with `assertions(...)`; it is evaluated after the simulation finishes, over whole-run statistics; and a failure exits `2` while an absent gate exits `0`. Adding the "no assertions means green" caveat unprompted is what separates someone who has wired this into a pipeline from someone who has read the reference page.