> For the complete documentation index, see [llms.txt](https://developer.harness.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://developer.harness.io/resilience-testing/load-testing/analyze-results.md). # Analyze Load Test Results After you run a load test, Harness opens the **Run detail** page and streams results in real time. The same page shows the final results after the run finishes. Every Load Test Engine uses the same Run detail layout: an **About This Test** panel, a row of summary cards, charts of users and throughput over time, the load test logs, and a per-endpoint statistics table. The engines differ in the detail. JavaScript (k6) reports **Failed Rate** with P50, P95, and P99 cards and adds a Response Time Histogram, while Java (JMeter) reports **Error Rate** and **Avg Response Time**. Select your engine below to see the walkthrough that matches your test. *** ### Access results Go to **Resilience Testing** > **Load Tests**. The page has three tabs. | Tab | What it lists | | ------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Executions** | Every run across all load tests, newest first. Each row reports the run identifier, **Users**, **Duration**, **Avg Response Time**, **Success Rate**, **Status**, and who started it. Filter by **Status** to isolate failures. | | **Load Tests** | The tests themselves, with **Mode**, **Infrastructure**, recent executions, and when each was last modified. Filter by **Type** or **Tag(s)**. | | **Composite Load Tests** | Pipelines that pair a load test with a probe. Go to [Composite load tests](/resilience-testing/load-testing/composite-load-tests.md) to review them. | To open a single run, select it from **Executions**, or open a test from **Load Tests** and choose a run from its execution list. Each execution is numbered and keeps its own results, so you can compare runs over time. A run in the **Executions** list that reports **Not Available** for response time or success rate did not produce metrics, which usually means it failed before generating load. Open the run and read its logs rather than the summary columns. *** ### Read the Run detail page {% @harness-package-selector/package-selector platforms="%5B%7B%22label%22%3A%22Python%22%2C%22slug%22%3A%22python%22%2C%22path%22%3A%22resilience-testing%2Fload-testing%2Fanalyze-results%2Fpython-analyze-results%22%7D%2C%7B%22label%22%3A%22JavaScript%22%2C%22slug%22%3A%22javascript%22%2C%22path%22%3A%22resilience-testing%2Fload-testing%2Fanalyze-results%2Fjavascript-analyze-results%22%7D%2C%7B%22label%22%3A%22Java%22%2C%22slug%22%3A%22java%22%2C%22path%22%3A%22resilience-testing%2Fload-testing%2Fanalyze-results%2Fjava-analyze-results%22%7D%5D" %} *** ### Interpret the results The following guidance applies to every engine. Where a metric name differs, the Python (Locust) name is given first. #### Healthy test indicators * **Error Rate** (or **Failed Rate**) stays at or near `0.00%`. * **Avg Response Time** and the **P95** / **P99** percentiles stay within your SLA or performance budget. * **Request Per Second** scales with active users during ramp-up. * The response time distribution clusters consistently without upward drift. #### Warning signs * **Error rate climbing during ramp-up:** the system may hit capacity before reaching the target user count. * **Response times rising over time:** a possible memory leak, connection pool exhaustion, or resource saturation. * **Throughput plateauing while users increase:** a bottleneck is capping request processing, such as CPU, database connections, or rate limiting. * **Scattered response time outliers:** intermittent issues like garbage collection pauses, DNS delays, or cold starts. * **One endpoint failing in Endpoint Statistics:** the problem is scoped to that route, not the whole service. #### Failed status A run shows **Failed** status when: * The test infrastructure lost connectivity during execution. * The load test process exited with an error. * The test was stopped before completion. * A threshold was breached, such as the 95th-percentile response time exceeding its limit. {% hint style="info" %} **STATUS REFLECTS EXECUTION HEALTH, NOT APPLICATION HEALTH** A high error rate does not by itself mark the run as **Failed**. A test that completes with a 100% error rate still shows as a completed run. Read the **Error Rate** or **Failed Rate** metric to assess how the application behaved, and use **Status** to confirm the test itself ran to completion. {% endhint %} *** ### Next steps * Go to [Get started with load testing](/resilience-testing/load-testing/get-started.md) to create and run your first load test. * Go to [JavaScript](/resilience-testing/load-testing/create-a-load-test/k6.md) to declare thresholds that gate a release on performance. * Go to [Composite load tests](/resilience-testing/load-testing/composite-load-tests.md) to pair a run with a probe that reports whether the service stayed healthy under load. * Go to [Key concepts](/resilience-testing/load-testing/get-started.md#key-concepts) to review virtual users, load profiles, and thresholds.