Skip to content

Errors Table Report Item

The errors table provide details about each error which occurred during the test. It allows to understand what happened server-side during the load test.

Errors Table Report Item

The table displays:

  • The time of the error,
  • The HTTP action that raised the error,
  • The HTTP error message,
  • The related failed assertions.

To view the error details:

  1. Find the error you want to inspect,
  2. Click on the Magnifier button on the right.
  3. A panel displays the detailed error.


The table doesn't display all the errors for performance and storage space reasons.

Edit Table

To customize the Errors Table, please refer to the documentation page about the legend and metrics.

The Errors Table only have one specific metric to display errors. So when editing it you can only select the following filters:

Edit Errors Table Report Item

Export as CSV

To export the table as a CSV files, please refer to the documentation page about exporting tables.

View Error

Each error can be inspected to display detailed information:

  • Number of errors: the number (and percentage) of this error message compared to the total hits on this request,
  • Occurred at: the exact time at which the error occurred,
  • In region: in which region the error has occurred,
  • On virtual user: which user profile and associated virtual users raised the error,
  • On container: the parent container of the action that failed,
  • On action: action which failed,
  • Message: the HTTP error message,
  • Connect time, latency ans response time: statistics related to the request in error.

An additional table displays the potential assertions that failed for the request.

And the Request and Response panels displays the request which has been sent to the server, and the received response.

Error Detailed information


You can search for Strings or Regular Expressions (JavaScript format) inside the request and response:

  1. Click on a code text area (headers or body),
  2. Type CTRL + F (or CMD + F on Mac), a dialog appears on top of the area,
  3. Type the text to search or a regex,
  4. Press Enter to start searching for the first term occurrence
  5. Press CTRL + G (or CMD + G on Mac) to find the next occurrence, or SHIFT + CTRL + G (or SHIFT + CMD + G on Mac) to find the previous one.

Understanding errors

Failure criterias

An error is triggered when:

  • The response code is 4XX or 5XX,
  • There is no response code (JMeter internal error message),
  • An assertion failed.

If you compare this to the virtual user validation, we are in the same situation than when there is no recorded content to compare the response with.

Displayed errors

To avoid overloading our reporting interface, we only store up to 2 errors for each combination of:

  • Load generator
  • Request
  • Response code

This way if a particular requests encounters two different response codes during the same test, you would see at least one of each in the Error table. While maintaining a manageable size for the error table at the same time.

4XX and 5XX codes

These codes can mean one of two things:

  • The application is failing,
  • The test scripts are incorrect.

Now to understand which one you are facing takes some analysis, using assertions can help pinpoint the failure accurately. Since we only display the requests that failed, assertions are a good way to make sure you provoke the failure at the right place. For instance, you could see an issue with a payment in the error table when in fact it's your login that failed earlier.

No response codes

When there is no response code, JMeter will output the error message in the response body. In OctoPerf we typically show a response header like this:


Now this can mean several things, it could be an issue with your scripts, for instance if a variable fails to be evaluated in the path, you might get something like this: Illegal character in path at index 39:${path}

But most of the time it is just related to the server not answering our requests. Because of this JMeter has no response code to display and it show an error message instead.

Network errors

When the application becomes hard to reach or even completely unreachable during the test, you might experience one of these response messages:

  • Connection reset
  • Socket closed
  • Read timed out
  • Remote host terminated the handshake
  • org.apache.http.NoHttpResponseException: XXXXX failed to respond
  • org.apache.http.conn.HttpHostConnectException: Connect to XXXXX failed: Connection timed out

All of these indicate that the remote server was either not answering or rejected our request. We take action to prevent such errors to occur because of our load generators. If the threshold table is empty, then look for issues on the network path between our agents and your servers.

To mitigate these issues, you can also try to increase the number of retries by editing properties.


We do not recommend doing this since network issues indicate bottlenecks that should be analyzed.

Routing errors

When the load generator cannot find a path to the application, you will face a message like this one: No route to host

This indicates that your application requires whitelisting to be accessed, try whitelisting the IP range of a particular AWS location or get in touch with OctoPerf sales team to purchase a dedicated IP.