A JMeter dashboard row shows Average 210 ms and 99th pct 8,900 ms — which samples fed each figure?

A row where `Average` and a percentile column disagree by an order of magnitude is the most common thing a JMeter report shows you. Before drawing any conclusion from it, be precise about what JMeter actually put into each column, because both come out of one pass over one list. ## One list, several reductions For every sample that reaches the statistics consumer, JMeter takes the sample's elapsed time and pushes that single number into six aggregators at once: the mean, the median, percentile 1, percentile 2, percentile 3, and the running min/max pair. The sample also increments `#Samples`, adds its received and sent bytes, and — if its success flag is false — increments `FAIL`. So `Average` and `99th pct` in one row are not measuring different things or different requests. They are two reductions of the identical list of elapsed times. ## What is in the list - **Failed samples are in it.** Nothing filters on the success flag before the elapsed time is recorded. A label whose failures return instantly pulls `Average` down; one whose failures time out pushes the percentile columns up. - **The whole reporting range is in it.** The row is a single aggregate across the run, or across the date range the report was told to cover. There is no per-interval breakdown anywhere in this table. - **Transaction Controller parents are in their own row.** They are excluded from the `Total` row only, so their durations do not appear twice in the run-wide figures. - **Empty controller samples are in nothing.** A controller that wrapped zero samples is dropped before aggregation. ## Which columns are single samples `Min` and `Max` are not aggregates at all — each is one recorded sample, the fastest and the slowest the label ever produced, printed as whole milliseconds. A `Max` far above the `99th pct` column tells you a single sample did that, and nothing about how often. By contrast `Average`, `Median` and the three percentile columns are printed to two decimal places, which is a useful tell when you are reading a screenshot: the two integer columns in the Response Times group are `Min` and `Max`. ## Where the time dimension lives If the question you actually have is *when* the slow samples happened, the Statistics table cannot answer it and no amount of squinting at the row will change that. The dashboard's other pages carry the time axis: 1. **Response Times Over Time** and **Response Time Percentiles Over Time** plot the same metrics against the clock. Both are bucketed at `jmeter.reportgenerator.overall_granularity`, which is `60000` ms — one point per minute — unless the report was generated with a different value. 2. The percentiles-over-time graph is titled *"Response Time Percentiles Over Time (successful requests only)"*, so its series and the Statistics table's percentile columns are computed over **different sample sets**. Comparing them number-for-number is a mistake. 3. **Response Time Distribution** and the synthetic distribution graph bucket the same samples by duration rather than by clock time. ## Reading the row honestly - Check `Error %` on the same row first: if it is non-zero, some of what you are reading in the response-time columns is the shape of the failures. - Treat the percentile headings as data. They render from the percentile values the report was configured with, so a report may legitimately show something other than `90th pct`, `95th pct`, `99th pct`. - The dashboard's percentile columns are estimates produced by a sliding-window estimator, and can differ from the figures the GUI's Aggregate Report gives for the same file. Which estimator is in play is a separate configuration question, but the fact that the two surfaces can disagree is worth knowing before you quote one against the other.