# Read a load-test report

A report shows recorded session outcomes, failures, timings and usage for a run. This guide explains how to interpret them.

## Test configuration {#scope}

Results relate to the scenario, environment and workload used for that run. The requested session count is spread over the arrival window; it is not a count of simultaneous users. See [sessions and concurrency](https://userlimit.com/documentation/concepts/sessions-and-concurrency.md).

## Session outcomes {#validity}

**Completed sessions** shows the number of recorded outcomes against the requested total. The **Failed sessions** summary shows the percentage of those outcomes that failed. The **Concurrent users** chart and any stop reason provide context for differences from the requested workload. Completed sessions includes failed outcomes and sessions that could not run; it is not a successful-visit count. Exact session start times are not shown in the report. Support can help investigate whether starts matched the requested traffic pattern. Script conversion problems, access blocks or difficulty starting sessions can prevent the intended workload. The [troubleshooting guide](https://userlimit.com/documentation/help/troubleshooting.md) covers these cases.

## Failures and timings {#inspect}

The report’s **Pages**, **API calls** and **Steps** tabs show timings for page loads, XHR/fetch requests and scenario actions. **Errors** groups session failures, **Failed requests** lists failed network requests and HTTP error responses, and **Locations** compares results by location when that data is available. **Average session duration** summarises the time taken by sessions. The report is not a full server trace or a complete archive of every network request.

The first failing action and grouped errors can help explain where the scenario broke down. Failed-step durations are excluded from timing summaries, so fast timings can appear alongside a high failure rate. The [metrics reference](https://userlimit.com/documentation/reference/metrics.md) explains which measurements are included. Application logs from the same period can help identify a backend cause.

## Comparing runs {#compare}

**Example comparison using fictional data.** Both runs request 600 sessions over ten minutes using the same scenario, location and traffic pattern. Run A tests release A and Run B tests release B in the same staging environment. Completed sessions includes failed outcomes.

| Observation | Run A | Run B |
| --- | --- | --- |
| Requested sessions | 600 | 600 |
| Completed sessions | 600 | 600 |
| Failed sessions | 0.33% | 6.67% |
| Average page-load time | 1.8 seconds | 3.1 seconds |

Failures rise from 2/600 (0.33%) to 40/600 (6.67%). Average page-load time increases by 1.3 seconds, about 72%. These averages include successful page-load measurements; they do not include failed-step durations.

Run B has more failures and slower page timings in this example. The release is one possible cause, but differences in actual traffic, access rules, caching or missing measurements can also affect the result. A repeat under comparable conditions can help narrow down the cause.

## What the comparison shows {#conclude}

“For the tested catalogue-to-product scenario, Run B recorded more failures and slower average page-load times at the same requested workload. We will investigate the failed product step and application logs, then repeat with the same configuration. Checkout, payment and real-user performance were outside this test.”

A Passed outcome reflects UserLimit’s error threshold, which may differ from your performance targets. The report can show a slowdown; identifying its cause usually requires application logs or monitoring as well.

## Possible next steps {#next}

A failed action can be investigated alongside application logs from the same period, while a repeat run after a specific change can show whether the result improved. Keeping the comparison conditions consistent makes that improvement easier to assess.

When the results are ready to share, a [client-facing summary](https://userlimit.com/documentation/recipes/client-summary.md) can explain the tested scope, recorded workload, findings and limitations, together with any agreed follow-up work.

## Related guide {#next-step}

[Write a client-facing summary](https://userlimit.com/documentation/recipes/client-summary.md)