Across a Gatling suite that gates CI, would you write the response-time budget as a `global` assertion, a `forAll` assertion, or one `details(...)` assertion per critical request, and how would you decide?

## The three shapes, and what each one buys Gatling gives exactly three assertion scopes, and choosing between them for a CI gate is a real design decision rather than a preference. They differ in coverage, in maintenance cost and in what a failure tells you: | shape | coverage | what a failure tells you | maintenance | |---|---|---|---| | `global()` | one rule over all requests pooled | that the run as a whole moved | none | | `forAll()` | one rule, evaluated per request type | which request types breached | none, but it binds every request | | `details(path)` per request | one rule per request you name | exactly which named request moved | breaks when a request is renamed | ## What each one actually costs **`global()`** is one rule and one verdict, and it aggregates across request types. That aggregation is precisely its weakness as a gate: a pooled statistic is dominated by the requests that produced the most traffic, so a rule on it can stay comfortably green while a low-volume request degrades badly. It is cheap, it never goes stale, and it is a poor instrument for catching the regression you most want to catch. **`forAll()`** is the coverage answer with no maintenance: it expands into one evaluation per request type and holds only if every one passes, so a new request added to a scenario is gated the day it appears. The cost is that it binds **every** request to the same budget — the login call, a health probe, a static asset fetch, a warm-up request. Any single one of them can turn the pipeline red for reasons that have nothing to do with the service's behaviour, and there is no exclusion mechanism in the grammar. A `forAll` budget is therefore necessarily set by your slowest legitimate request, which usually means setting it loose enough that it stops discriminating. **`details(path)` per critical request** is the precise option, and the only one whose failure message names the thing that moved without further investigation. Its cost is coupling: the path is an exact match against the request's full name, group prefix included, and there is no exclusion or wildcard. Rename the request in the scenario and the assertion no longer resolves — which, in Gatling, is a **failed** assertion rather than a skipped one. That behaviour is the right default, but it means a `details` gate is a maintenance obligation, not a write-once artefact. ## How the decision usually resolves There is no single right answer, but there is a shape that most teams converge on, and it exploits the fact that `assertions(...)` takes any number of rules and ANDs them: 1. **A small set of `details(...)` rules on the journeys that carry the business**, each with its own budget. These are the rules people read when the pipeline goes red, and they are worth the maintenance. 2. **A loose `forAll()` rule as a safety net** — a failure-rate or a gross latency ceiling that no healthy request should ever approach. Its job is not to discriminate but to catch a request that nobody wrote a specific rule for and that has broken badly. 3. **A `global()` volume floor** on `allRequests().count()`, so a run that produced almost no traffic cannot report a pass simply by having nothing to fail. That layering gives precise diagnosis where you invested, coverage where you did not, and a guard against the empty run. It is more rules than a single gate, but each one is cheap and every one prints its own verdict line. ## The judgement calls that remain Three things are genuinely contested and worth having a position on: - **How much coupling to accept.** Every `details` path is a dependency on a request name. Either treat request names as a stable interface that reviews defend, or accept that gates will go red on renames and budget for the churn. Both are defensible; drifting into the second without saying so is not. - **Whether a broken gate should be loud.** An unresolvable `details` path fails, so a rename produces a red run rather than silent loss of coverage. Teams under delivery pressure are tempted to remove the rule; removing it is exactly the outcome the failure exists to prevent. - **Where the rules live.** Assembling assertions from a shared base class is the shape that most often loses them, because a second `assertions(...)` call replaces rather than appends in the Java API. Prefer a single call fed from a list. What the budget numbers themselves should be is a separate question with its own discipline, and it is not answered by the choice of scope.