> OctoPerf's load testing - Errors Table Report Item documentation page. Errors Table Report Item edition and usage.

Source: https://api.octoperf.com/doc/analysis/edit-bench-report/report-items/errors-table/

# 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](https://api.octoperf.com/doc/analysis/edit-bench-report/report-items/img/errors-table-item.png "Errors Table Report Item")


| Name          | Description                                                                                                                       |
|---------------|-----------------------------------------------------------------------------------------------------------------------------------|
| Virtual user  | The name of the **Runtime profile** or by default **Virtual user + region**                                                       |
| Container     | **Parent** container or request                                                                                                   |
| Action        | **Request** (or sampler) that failed                                                                                              |
| Error         | **Error** message                                                                                                                 |
| Assertions    | [Assertions](https://api.octoperf.com/doc/design/edit-virtual-user/action-types/post-processors/response-assertion/) failed on this request/sampler |
| Time          | **Time** of the error converted in your browser local time.                                                                       |

## Configuration

To customize the Errors Table, please refer to the documentation page about the [legend and metrics](https://api.octoperf.com/doc/analysis/edit-bench-report/metrics-selection/). Only **location** and **virtual user** can be used as filters.

![errors-table-item-configuration.png](https://api.octoperf.com/doc/analysis/edit-bench-report/report-items/img/errors-table-item-configuration.png)

!!! warning
    To improve readability, on the SaaS platform the table only displays 2 errors per (load generator + request + error code). You can change this behavior in the [settings of your on premise platforms.](https://api.octoperf.com/doc/on-premise-infra/configuration/#errors-storage)

## Export

To export the table please refer to the [dedicated documentation page](https://api.octoperf.com/doc/analysis/export-bench-report/export-report-items/#exporting-tables).

## Error details

Click on **Inspect Errors** 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,
* __Timings__ of this particular request,
* __Message__: the error message or code,
* __Region__: in which region the error has occurred,
* **Injector**: load generator container name,
* __Virtual user__: which user profile and associated virtual users raised the error,
* __Container__: the parent container of the action that failed,
* __Action__: action which failed,

An additional table displays the potential [assertions](https://api.octoperf.com/doc/design/edit-virtual-user/action-types/post-processors/response-assertion/) 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](https://api.octoperf.com/doc/analysis/edit-bench-report/report-items/img/errors-table-item-inspect.png "Detailed Error View")

!!! info
    You can search inside headers or bodies using the same functions as the [code editor](https://api.octoperf.com/doc/design/edit-virtual-user/code-editor/) available throughout OctoPerf.

### Open in design

Click **Open in design** at the bottom of the dialog to fix the failing action: OctoPerf opens the [Virtual User](https://api.octoperf.com/doc/design/edit-virtual-user/) the error comes from, on the action that failed. If this action no longer exists in the Virtual User, the closest parent that still exists is opened instead.

The button is disabled when the Virtual User is no longer in the design project; its tooltip then tells you so.

## Error count

Click on **Count Errors** to display the number of error occurrences and their percentage in the upper right corner of the application:

![errors-table-item-count.png](https://api.octoperf.com/doc/analysis/edit-bench-report/report-items/img/errors-table-item-count.png)

## 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](https://api.octoperf.com/doc/design/edit-virtual-user/action-types/post-processors/response-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](https://api.octoperf.com/doc/design/edit-virtual-user/validation/#error-matrix) 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](https://api.octoperf.com/doc/design/edit-virtual-user/action-types/post-processors/response-assertion/) 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:

`HTTP/1.1 -1 - UNKNOWN`

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:

`java.net.URISyntaxException: Illegal character in path at index 39: https://petstore.octoperf.com/actions/${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:

- `javax.net.ssl.SSLException: Connection reset`
- `javax.net.ssl.SSLException: Socket closed`
- `java.net.SocketTimeoutException: Read timed out`
- `javax.net.ssl.SSLHandshakeException: 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](https://api.octoperf.com/doc/analysis/edit-bench-report/report-items/monitoring-alarms-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](https://api.octoperf.com/doc/design/edit-virtual-user/configuration/files/#edit-jmeter-settings).

!!! warning
    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:

`java.net.NoRouteToHostException: No route to host`

This indicates that your application requires whitelisting to be accessed, try [whitelisting the IP range of a particular AWS location](https://api.octoperf.com/doc/runtime/ip-ranges/) or get in touch with [OctoPerf sales team](mailto:sales@octoperf.com) to purchase a dedicated IP.