In a Gatling HTML report, what do the gatling.charting.indicators.percentile1 to percentile4 settings change, and which chart do they not affect?

## The four slots Gatling does not hardcode which percentiles its tables show. Four settings choose them: ```hocon gatling.charting.indicators { percentile1 = 50 percentile2 = 75 percentile3 = 95 percentile4 = 99 } ``` Those are the defaults from `gatling-defaults.conf`. They are read as **doubles**, not integers, so `percentile4 = 99.9` is a legal and useful setting — a common one, since a 99th percentile over a short run is often only a handful of samples. What the slots drive: - **The Stats table's four percentile columns**, on `index.html` and on every request and group detail page. The column headers are built from the configured ranks, so changing a slot renames the column as well as refilling it. - **The end-of-run console summary**, which prints the same four statistics as lines in its Global Information block. - **The `percentile1()` to `percentile4()` metrics in the assertion chain**, which read the same four configuration values. That coupling is the practical reason to think before retuning a slot: an assertion written against slot three quietly starts asserting on a different rank. ## The chart the slots do not touch This is the part the question is really about. The **Response Time Percentiles over Time** chart does **not** read the four slots. For each time bucket of the run Gatling computes a fixed ladder of ranks and plots them as bands: | plotted by the chart | configurable? | |---|---| | minimum, 25th, 50th, 75th, 80th, 85th, 90th, 95th, 99th, maximum | **no** — fixed | | the four Stats-table columns | **yes** — `percentile1` to `percentile4` | So setting `percentile4 = 99.9` adds a `99.9th pct` column to the table and changes absolutely nothing on the chart, which still tops out at a 99th-percentile band. If you need a 99.9th percentile *over time* from a Community Edition run, the static report will not draw it — you get the figure for the run as a whole in the table, not as a curve. The **Response Time Distribution** histogram is likewise untouched: its buckets come from the data, not from the slots. ## When the figures are computed Everything here happens at **report-generation** time. `simulation.log` holds raw per-request timings; the percentiles are derived while the HTML is being written, from whatever configuration is resolved at that moment. Two practical consequences: 1. **You can change your mind after the run.** Edit the slots, regenerate with `--reports-only` (`-ro <directoryName>`) against the existing results folder, and the new columns appear without re-executing anything. 2. **Two engineers can get two different tables from one run** if their configuration differs, so the charting settings belong with the simulations rather than on a laptop. One implementation detail worth knowing: Gatling estimates these percentiles from a t-digest sketch rather than by sorting every sample. The figures are close approximations, not exact order statistics, and that is a deliberate trade for being able to summarise millions of samples in bounded memory. ## Which population each figure covers A slot says *which rank*; it says nothing about *which requests*. On the **global** page the four percentile columns are computed over all requests, failures included. On a **request detail** page the same four ranks are printed three times — `Total`, `OK` and `KO` — so you can see the success distribution and the failure distribution separately. The percentiles chart, by contrast, is success-only everywhere. Keeping rank and population apart in your head is what stops the table and the chart looking contradictory. ## Where the slots are set The four keys resolve through Gatling's normal configuration chain: a system property beats `gatling.conf`, and `gatling.conf` beats the shipped `gatling-defaults.conf`. `gatling.conf` itself is resolved from the **classpath**, not from a path on disk, so in a typical build it lives beside the simulations in the test resources. That placement is what makes a team's reports comparable — the alternative, leaving each engineer's machine to supply the ranks, produces tables that quietly disagree about what their own columns mean. ## What stays outside Which rank a team *should* watch, whether per-interval percentiles can be combined into one run figure, and what a percentile means at all are performance-testing questions rather than Gatling ones. Gatling's contribution is narrow and worth stating exactly: four configurable slots that fill the table and the console summary, a fixed ladder that fills the chart, an assertion metric that reads the same four slots, and every one of those figures derived after the fact from the same log.