Error Analysis

Understanding the Errors Report

The Errors tab in your LoadFocus test results shows every failure that occurred during your JMeter load test, once the test has finished. It plots error counts and response codes over time, with a time-range slider, a request filter and granularity controls, so you can see when and where the test began to fail.

Load Testing Errors Example

Key Features

  • Error Timeline One chart with a red Errors line per request and a blue line per response code (for example 200 or 503) with its count. Tick Error rate % to add a dashed red line for the share of failed requests per second.
  • Time Range Slider Adjust the FROM/ TO handles to zoom into any interval of your test run.
  • Granularity Selector Choose Raw, 100ms, 500ms, 1s (the default), 1min or 5min. Raw, 100ms and 500ms need a paid plan. See Granularity.
  • Request & Response Code Filters In the left panel, type in Filter requests to find a request, and tick the Errors and Response Codes checkboxes you want on the chart. Reset to Default clears them.
  • Errors by Type A table of what failed: the error type (an HTTP status code or a connection, SSL or socket error), the request, the number of errors and the share of all errors. A +N button lists the other messages behind a row. See Errors by Type.

How to Use the Errors Tab

  1. Run Your Test Launch your JMeter .jmx load test on LoadFocus and wait for it to finish.
  2. Open "Errors" Click the Errors tab on the results page.
  3. Filter by Time Drag the slider handles at the top to restrict your view to the precise period of interest.
  4. Select Granularity Pick a granularity that matches your investigation needs (e.g., 1 s for spike detection, 1 min for trending).
  5. Apply Request Filters Use the left-hand panel to switch requests and response codes on and off.
  6. Hover for Details Hover over the graph to see the exact timestamp and the value of each plotted line.

Interpreting Error Trends

  • Isolated Error Spikes A short burst of errors followed by recovery may indicate transient network issues, resource throttling, or external service hiccups.
  • Sustained Error Periods Continuous errors suggest systemic problems such as server overload, configuration errors, or capacity limits.
  • Error vs. Hit Ratio Compare the red Errors line with the blue response-code lines: if errors rise while the 200 count drops or plateaus, your system may be rejecting requests under pressure.

Drilling Down

  • View Error Details Read the messages in the Errors by type table, or open the Logs tab and download the JTL file: its failureMessage column explains each failed sample. See Logs & JTL File Analysis.
  • Correlate with Engine Health Switch to Engine Health to see if CPU, memory, or I/O saturation coincides with your error spike.
  • Check Sampler-Specific Failures Use Filter requests to isolate which HTTP Request, JDBC Request or other sampler is failing.

Best Practices

  • Set an Error Threshold Add a Max error rate pass/fail threshold so a run is marked failed when reliability degrades. See Pass/Fail Thresholds.
  • Baseline Your Environment Run a low-load sanity test to determine your system's normal error floor. Zero errors under light load is the goal.
  • Isolate the Window Once you see an error window, narrow the slider and request filter to that window, then check the same time range in the Engine Health tab.
  • Combine Views Always cross-reference Errors, Insights, Timeline, and Engine Health for a holistic diagnosis.
Previous
Engine Health Monitoring
Next
Load Testing Insights