In JMeter's HTML dashboard, what do the four columns of the Errors table show?
answer
- Four columns, two different denominators
- Key is code plus response message
- Success codes point at an assertion
- A second table pivots by sampler
basics
~20 sThe Errors table lists Type of error, Number of errors, % in errors and % in all samples, one row per distinct failure key — unlike the Statistics and APDEX tables it has no Total row. The key is normally the response code and message.
solid answer
~50 sThe four columns are `Type of error`, `Number of errors`, `% in errors` and `% in all samples`. The last two have different denominators: `% in errors` is the row's share of **all failures**, while `% in all samples` is its share of **every sample** the report covers — so one row can read `100%` and `0.4%` on the same line. The `Type of error` key is built as `responseCode/responseMessage`. When the response code is itself a success code — a `200` rejected by an assertion — JMeter replaces the key with the assertion's failure message, or with the literal `Assertion failed` when failure messages are not saved to the results file. Transaction Controller samples are excluded from this table. Below it, **Top 5 Errors by sampler** breaks the same failures down per sampler, and excludes transaction controllers by default.
go deeper
Know the Errors table exists below the Statistics table and names each distinct failure with a count, rather than just totalling them.
Explain that the key is the response code plus message, and that the two percentage columns divide by different things — all failures versus all samples.
Recognise a row keyed by an assertion message as a sampler that returned a success code, and know that turning off failure-message saving collapses them into one uninformative row.
Set the saveservice defaults your teams run with so error keys stay meaningful, and treat a report whose errors all read Assertion failed as a configuration defect rather than a result.
The Errors table is the fifth panel on the dashboard's index page — after Test and Report information, the side-by-side APDEX and Requests Summary pair, and Statistics — and sits directly under the Statistics table. It answers *what went wrong*, where the Statistics table's `FAIL` column only answers *how many*. ## The four columns | Column | What it holds | |---|---| | `Type of error` | the failure key, one row per distinct value | | `Number of errors` | how many samples produced that key | | `% in errors` | that count as a percentage of **all failed samples** | | `% in all samples` | that count as a percentage of **every sample** in the report | There is no `Total` row here: the errors consumer is built without an overall result, which is why `% in errors` sums to 100 down the column instead. The two percentage columns are the part worth slowing down for. A single row reading `100.00%` in one and `1.18%` in the other is not a contradiction: it means this failure accounts for every failure in the run, and the run's failures account for a bit over one percent of its samples. Quote the wrong column and you either panic or you miss the problem entirely. The table is sorted by `Number of errors` descending by default, so the dominant failure is at the top. ## How the key is built `ErrorsSummaryConsumer` derives the key from each failed sample: 1. Start with `responseCode`, and append `/` plus the `responseMessage` when there is one — giving keys like `500/Internal Server Error` or `Non HTTP response code: java.net.SocketTimeoutException/Non HTTP response message: Read timed out`. 2. If that response code is itself a **success** code, the sample failed for another reason — almost always an assertion — so the key is replaced. 3. The replacement is the sample's assertion failure message when one was saved, and the literal string `Assertion failed` otherwise. Whether the message is saved is governed by `jmeter.save.saveservice.assertion_results_failure_message`, which defaults to true and only affects CSV output. 4. A sample with an empty response code but a non-blank failure message is treated the same way. The practical consequence: if you turned that save setting off to shrink the results file, every assertion failure in the report collapses into one row called `Assertion failed`, and the table stops telling you which assertion. Response messages are HTML-escaped and JSON-encoded before they become keys, so a message containing markup renders as text rather than breaking the page. ## What is excluded - **Transaction Controller samples.** They are filtered out before this consumer sees them, so a failing parent does not appear alongside the child that actually failed, and the `% in all samples` denominator is free of them. - Nothing else is filtered on the error path — the sample name filter and the date range still apply, because they sit upstream of it. ## The table below it **Top 5 Errors by sampler** takes the same failures and pivots them: `Sample`, `#Samples`, `#Errors`, then up to five `Error` / `#Errors` pairs per row. It answers *which sampler produced which failures*, which the flat Errors table cannot. Transaction Controllers are excluded from it by default, under `jmeter.reportgenerator.exclude_tc_from_top5_errors_by_sampler`, which ships set to `true`. Read the two together: the Errors table tells you what the dominant failure is, and Top 5 Errors by sampler tells you where it landed.
- Why might a JMeter Errors table row read 'Assertion failed' with no further detail?Because the sampler returned a success code and the assertion's failure message was not available to the report. JMeter falls back to the literal string Assertion failed when no message was saved, which happens if jmeter.save.saveservice.assertion_results_failure_message was turned off for that run.
- How do the two percentage columns of JMeter's Errors table differ?% in errors divides by the total number of failed samples, so the column sums to 100 across the table. % in all samples divides by every sample in the report, so it sums to the run's overall error rate. One row can be 100% of the failures and a fraction of a percent of the traffic.
saying these in an interview costs you the question
- Reads % in errors as the run's error rate
- Expects an HTTP status code on every row
- Assumes assertion failures never reach this table
- Thinks Transaction Controller failures appear here
- Believes the two percentage columns share a denominator