Load testing report: what to include, how to read It, and a free template

A load testing report turns a performance test into a decision. It states whether the system met its objectives under a defined workload, where it broke, why, and what happens next. Your load testing tool generates the charts for you. The decision is the part no tool writes.

Here is why that matters. In one Gatling demo run, mean response times looked healthy across the board. The p99 for the home page told a different story: some users waited up to 2 seconds. A report that leads with averages ships that release. A report that leads with percentiles against agreed targets catches it.

This guide covers what goes into a load testing report, how to read one, how to check the numbers can be trusted, and how to move from one-off reports to trends you can gate releases on. A copy-paste template is at the end.

What is a load testing report?

A load testing report documents the conditions, results and conclusions of a test that applied a defined workload to a system. A useful one answers four questions:

1. Did the system meet its objectives? A pass, fail or conditional verdict against criteria set before the run.
2. At what load did behavior degrade or break? The practical capacity, with headroom against expected peak.
3. Why? The bottleneck, backed by evidence from the client side and the server side.
4. What should we do next? Prioritized actions, each with an owner and a retest plan.

The HTML report your load testing tool produces is not the load testing report. It is evidence. The JMeter dashboard, the Gatling HTML report and the k6 end-of-test summary give you percentiles, throughput and errors. They don't tell you which objective was at stake, whether the environment matched production, or whether the release should go out. That interpretation is the report.

One terminology note: "load test report" also describes inspections of diesel generators and cranes. This guide is about software performance testing of web apps, APIs and services.

Who reads it, and why one report doesn't fit all

The people who write load tests are rarely the people who decide what to do with the results. An engineer can read a p99.9 curve. A release manager needs to know whether to ship on Thursday. Both need the same report, at different depths.

The practical answer is a two-layer report. The top layer is a one-page decision summary: verdict, headline numbers against targets, top risks, the decision requested. Underneath sits the engineering evidence: full metrics, root causes, configs and raw data.

Gatling Enterprise reports follow the same split. The Summary tab shows error ratio, total requests, max concurrent virtual users, p95 response time and assertion status. The Report tab holds the drill-down panels for requests, groups, users, connections, DNS and load generators. The data is for engineers. The decision has to make sense to everyone.

What to include: the 12 sections

A complete load testing report has 12 sections. Short tests in CI can compress several into a line each, but none should be missing.

1. Executive summary: Verdict (pass, fail, conditional), headline numbers against targets, maximum validated load, top three risks, decision requested. One page, no jargon.
2. Objectives: The question the test answers. Example: "Can checkout sustain 2x last Black Friday's peak at p95 under 800 ms?"
3. Pass/fail criteria: Percentile, error-rate and throughput targets, globally and per critical transaction. Written before the run.
4. Scope: Journeys and endpoints included, what was excluded, and assumptions.
5. Environment: Application build, infrastructure sizes, database volume, autoscaling settings, load generator locations and count, tool and version.
6. Workload model: Open or closed, and why. Injection profile (ramp, plateau, duration), scenario mix, think time, test data strategy.
7. Test types run: Smoke, load, stress, spike, soak or capacity, each with its own verdict.
8. Results: Percentile tables per transaction, throughput, error breakdown, time-series charts.
9. Bottleneck analysis: Each finding as observation, evidence, impact, root cause, recommendation.
10. Measurement validity: Achieved versus intended load, generator health, warm-up handling.
11. Recommendations and next steps: Prioritized, owned, with retest criteria.
12. Appendix: Script commit, configs, raw data, links to the tool's reports and dashboards.

Most templates you'll find online cover sections 1, 2, 5, 8 and 11. Sections 6 and 10 are the ones that decide whether anyone should believe section 8. Skip the environment details and nobody can tell whether a regression came from the code or from a smaller database instance.

The metrics that belong in the report

Lead with response time percentiles, error rate and throughput, then add the load you applied and what the servers were doing. Everything else supports those five.

Response time percentiles, not averages

Report p50, p95, p99 and, for high-volume systems, p99.9. Show the max as a diagnostic, never as a gate: one slow TLS handshake can own it.

The mean is a sanity check at best. Gatling's documentation is explicit that mean and standard deviation only describe symmetric, single-peaked distributions. Real response times are skewed, multi-modal and heavy-tailed. Two very different distributions can share the same mean.

Two rules most reports break:

• Never average percentiles: The average of three generators' p95 values is not the p95 of the test. Compute percentiles from merged raw data or histograms.
• State the sample count: A p99 from 400 requests rests on 4 data points.

Throughput

Requests per second, and business transactions per second where they differ. Throughput only means something next to latency and errors: 5,000 requests/s with a p99 of 6 seconds is not a success.

Errors

Error rate overall and per request, broken down by status code or exception, and plotted over time. Did errors start at a specific load step? That timing is often the best clue in the whole report.

Report the latency of failed requests separately. Fast failures, like an instant 503, make blended latency look better than reality. Gatling's percentiles-over-time chart covers successful requests only for this reason.

The load you actually applied

State both arrival rate (users or requests started per second) and concurrency (users active at once). "1,000 users" means nothing without pacing and journey length. In an open model, concurrency rising at a constant arrival rate is itself a symptom: requests are piling up.

Connection timings

Gatling's response time includes DNS resolution, TCP connect and TLS handshake unless a connection is reused. Both Gatling editions report percentiles for each of those separately. When latency jumps, this tells you whether the cost is in your code or in connection setup, for example a load balancer that stopped reusing connections.

Server-side metrics

CPU, memory, garbage collection pauses, thread and connection pools, database query time and locks, queue depth, network I/O and autoscaling events. Put them on the same timeline as the client-side charts. A correlation you can see is worth more than one you describe.

Can you trust the numbers? The section most reports skip

A report is only as good as the test behind it. Four checks decide whether the results describe your system or an artifact of how you tested it.

Open or closed workload model

In a closed model, you fix the number of concurrent users. A new user starts only when another finishes. In an open model, you fix the arrival rate. Users keep arriving whether the system is fast or slow.

Most internet traffic is open: shoppers don't wait for other shoppers to finish checking out. Simulate an open system with a closed model and your test slows its own arrivals as the system degrades. It hides exactly the overload you were looking for. Gatling's documentation puts it bluntly: if you get this wrong, "your test is broken."

Closed models fit systems with a genuinely bounded population, like a call center or a queue with a fixed number of workers. In Gatling, injectOpen takes arrival-rate profiles such as constantUsersPerSec and rampUsersPerSec. injectClosed takes constantConcurrentUsers and rampConcurrentUsers. Write the model and the reason for it in the report.

This matters across teams too. When one team tests with a closed model and another with an open one, their p95 numbers can't be compared, and trust in the data erodes.

Coordinated omission

When a load generator waits for each response before sending the next request, a server stall pauses the test too. The slow period gets a handful of samples instead of the hundreds it should have. Gil Tene, CTO of Azul Systems, named this coordinated omission. He showed it can make reported percentiles "1-3 orders of magnitude better than what really happens."

In one traced example, a 1-second server stall produced a p99 of 5 ms in a closed-loop test and 950 ms in an open-loop test. An open workload model, where new users arrive on schedule regardless of response times, keeps the stall in the data. If a percentile chart shows a sudden vertical jump, check this before you trust the tail.

Load generator health

A saturated load generator under-delivers load and inflates client-side latency. The report then blames the system for a problem in the test rig. Record generator CPU, memory and connection activity. Gatling Enterprise monitors each load generator's CPU usage and TCP connection events per second on the run report. Gatling's non-blocking engine helps here: up to 60,000 concurrent virtual users or 300,000 requests per second on a single load generator, so fewer machines to watch.

Also confirm the achieved arrival rate matched the intended profile. If you planned 200 users/s and delivered 140, say so on page one.

Warm-up and cool-down

Caches, JIT compilation, connection pools and autoscaling make the first minutes unrepresentative. Exclude ramp-up and ramp-down from your verdict, and state that you did. Gatling Enterprise lets you set time windows that remove those periods from assertion and SLO computation.

How to read a load testing report

Read the verdict first, then check the load was what you intended, then look for the point where latency stops behaving. Five charts do most of the work.

1. Response time against load. Plot p95 and p99 against requests per second. Latency stays flat, then bends upward. That bend, the knee, is your practical capacity. Report it with the headroom against expected peak. Gatling's HTML report includes this view per request and group; JMeter's dashboard has "Response Time vs Request per second."
2. Percentiles over time. Shows when degradation started and whether it recovered. A widening gap between p50 and p99 means a growing share of users is waiting on something, often a queue.
3. Active users and arrival rate over time. Confirms the injection profile ran as designed. Under an open model, active users climbing while arrivals stay flat means requests are taking longer.
4. Errors over time. Errors that start at a specific load step point to a resource running out. Errors spread evenly point to a functional bug.
5. Server-side metrics on the same timeline. The chart that turns a symptom into a cause.

Once you can see the shape, match it against the common signatures:

Correlate before you conclude. A root cause in the report should point to a metric, trace or log that moved at the same moment as the client-side symptom. CPU rising alongside latency is a correlation; a trace showing time spent waiting for a database connection is evidence.

This is also where real bottlenecks surprise you. InPost ran a five-day logistics simulation to prepare for growth from 1.6 million to 10 million parcels a day. As SRE Mateusz Piasta put it, "The five-day test revealed bottlenecks from code to cables." The fixes ranged from cache tuning and database indexes to replacing physical connectors between servers and storage arrays.

Spot pass/fail criteria before you run

A verdict needs criteria, and criteria written after the results are in tend to bend toward the release date. Agree them up front and put them in the test.

Where the numbers come from

There is no industry standard that says p95 must be under 500 ms. Take thresholds, in this order, from contractual SLAs, agreed SLOs, capacity forecasts and your own baselines. A read API and a checkout flow deserve different targets.

Encode them as assertions

In Gatling, assertions are acceptance criteria evaluated after the run. A failed assertion makes the run exit with a non-zero code, which fails the CI build like a failing unit test.

setUp(
  scn.injectOpen(rampUsersPerSec(10).to(100).during(600))
).protocols(httpProtocol)
 .assertions(
   global().responseTime().percentile(95.0).lt(500),
   global().failedRequests().percent().lt(1.0),
   details("Checkout", "Place order").responseTime().percentile(99.0).lt(1200)
 );

The JavaScript and TypeScript SDKs use the same chain, and so do Kotlin and Scala with their own syntax. Note the third assertion. A global p95 can pass while a critical endpoint fails, because thousands of fast static or health-check requests dilute one slow checkout call. Add per-request or per-group assertions for every journey that matters to the business.

SLOs for continuous evaluation

Assertions check the run as a whole. SLOs in Gatling Enterprise evaluate a target continuously and report the share of time it held: green at 99% or more, orange from 90 to 99%, red below 90%. That tells you whether checkout breached its target for 30 seconds or for 20 minutes. When SLOs are configured on a test, they replace code-defined assertions for that run.

Stop criteria complete the setup. They end a run early when mean CPU, global error ratio or a response time percentile crosses a threshold, so you don't burn a full hour hammering a system that failed in minute five.

From one report to a trend: baselines and regressions

A single report describes one moment. Regressions creep in commit by commit, so the report that catches them compares this run against the last ones.

Compare like with like

A baseline is a reference run you compare future runs against. It only works if the script, workload model, test data and environment stay the same. Report deltas per transaction, not just globally: a 4% global change can hide a 40% regression on one endpoint.

Run twice before you call a regression. Cloud scheduling, caches and garbage collection add noise between runs. Define the regression threshold in advance, for example a p95 increase over 10% on a critical transaction.

What this looks like in Gatling Enterprise

• Run Trends shows the last 10 successful runs of a test: OK and KO responses, percentiles from p50 to p99.9999 plus max, and throughput.
• Run Comparison overlays up to 5 runs across 11 metrics, with the percent deviation for each request.
• Campaigns group tests around a purpose, such as "checkout production readiness," and score every run from 0 to 100. The score averages three categories: methodology (is the test named, typed and given objectives), objectives (did it complete and meet its SLOs) and confidence (did the last three runs pass consistently).
• CI/CD integration returns the run ID, report URL and assertion results as JSON. A deploy that regresses p95 by 15% can fail the pipeline automatically.

A release gate in practice

Nickel, a BNP Paribas subsidiary with 4.5 million accounts, runs performance tests as a mandatory release gate. Each app must "show a clean record," meaning no degradation against its previous version, before the Change Advisory Board approves deployment. Monthly social benefit payments drive 20 to 30 times normal traffic, and every authorization must still complete in under 3 seconds.

The reports also serve as auditable proof of reliability for regulators. Moving to Gatling Enterprise changed how the team produces them. As Alexandre Baert, Pre-production Platform Manager, put it: "We used to export CSVs and graphs by hand. Now we compare runs directly and get useful insights in real time."

AI-generated summaries: a fast first draft, not the verdict

AI can now write the narrative part of a load testing report in seconds. Use it to draft, and keep the pass/fail decision with your criteria and your team.

Gatling Enterprise has three AI analysis features, each generated on demand from the report:

Each analysis carries a confidence badge: low, medium or high. Low confidence can mean a run stopped early, or the compared runs differed too much to support a firm conclusion. Comparisons work best between runs with the same shape, injection profile and variables.

Where AI summaries earn their place:

• The first draft of the executive summary. Copy the written analysis into Slack or a Jira ticket for people who will never open a dashboard.
• Triage across many runs. Spot which tests are degrading before reading every chart.
• Pointing to the right chart. The comparison names which metrics and run pairs to inspect.

Where they don't replace you: Gatling's own documentation labels these analyses informational and says to always verify results before making decisions. Generating a summary twice on the same data can produce slightly different wording. The verdict that gates a release should come from assertions or SLOs you defined, not from generated prose.

Reporting on LLM and AI-backed services

If the system behind the endpoint is an LLM, a standard report will measure it with the wrong ruler. A p95 under 500 ms makes no sense for a call that legitimately streams for 5 seconds. Add four things.

• Time to first token (TTFT), separate from total time. TTFT decides whether the experience feels alive; total generation time decides throughput and cost. They scale with different inputs: prompt size drives TTFT, output length drives total time. Report both at p50, p95 and p99.
• Throughput in tokens per second. Requests per second is a weak unit when one request returns 50 tokens and the next returns 500.
• Cost per run and per successful outcome. Every request costs money, and slow requests are usually the expensive ones. A truncated answer you paid for counts as waste. Assert on a budget, such as a maximum spend per hour of load.
• Graceful degradation. Past capacity, does the system shed load cleanly with fast 429s and 503s, or does latency cascade? For AI services, "bends but doesn't break" is a realistic pass criterion. "Never fails" is not.

The methodology section matters even more here. Drive the test from a corpus of real prompts in short, medium and long buckets, not one canned string, which also avoids measuring cheap prompt-cache hits. Use an open workload model, since inference pools queue requests rather than rejecting them, and model client timeouts and retries, where retry storms start. HTTP 200 is not success either: check the response body for truncation.

Gatling handles streaming LLM APIs through server-sent events, with JSON checks applied directly to event fields. Gatling's LLM load testing benchmark shows what this looks like in practice: TTFT reported separately for each model and prompt size.

How common tools produce reports

Every major tool generates the evidence layer. They differ in what happens after one run: history, comparison, sharing and gating.

Each has genuine strengths. JMeter's dashboard computes Apdex per transaction with no setup. k6's handleSummary() lets you output almost any format. Locust's live web UI makes exploratory runs easy to watch. Commercial platforms such as LoadRunner, NeoLoad and BlazeMeter also offer run comparison and executive reporting, with integrations into APM tools like Dynatrace and Datadog.

The pattern across open-source tools is the same: one static report per run, with no history, no comparison and no sharing. That was fine when teams tested twice a year. When tests run on every merge, the report you need is the trend, and producing it by hand from exported CSVs is where performance practices stall.

10 common mistakes

Run through this list before you send a report.

• Leading with average response time: Put p95 and p99 against targets on page one.
• Averaging percentiles across generators, nodes or runs: Recompute from raw data or histograms.
• Setting thresholds after the run: Agree criteria before execution and encode them as assertions or SLOs.
• Only global assertions: Add per-request or per-group criteria for every business-critical journey.
• A closed model for an open system: The test slows its own arrivals and hides the overload.
• Ignoring generator health: Show generator CPU and achieved versus intended load.
• Including warm-up in the verdict: Exclude ramp-up and ramp-down, and say so.
• No environment details: Without build, sizes and data volume, nobody can reproduce or compare the run.
• Comparing unlike runs: Different scripts, data or environments make deltas meaningless.
• A data dump with no recommendation: Every finding ends with an action, an owner and a retest plan.

Load testing report template

Copy this template into your wiki, doc or repository. The results section mirrors the Gatling Community Edition HTML report block by block: run information, assertions, stats, response time ranges, errors and charts. You can move numbers straight across. The rest (objectives, environment, server-side metrics, recommendations) comes from your own notes and monitoring, because no HTML report knows them.

Write the report for the incident you haven't had yet

Most load testing reports are written for the release meeting. Their most important reader often shows up months later, during an incident, asking one question: did we ever test this?

That reader doesn't need your charts. They need to know what load you applied, with which workload model, against which build and environment, and what the system did at its limit. If the report answers that, it turns a 2 a.m. debate into a lookup. If it only says "PASS," it answers nothing.

Three habits follow from that.

Treat every verdict as having an expiry date. A pass is true for one build, one environment, one traffic mix. New features, data growth and infrastructure changes quietly invalidate it. Write the conditions next to the verdict, and retest when any of them change.

Record where it broke, not just whether it passed. "Passed at 1,000 users/s" says little about headroom. "Passed at 1,000 users/s, degraded at 1,400, connection pool exhausted at 1,600" tells capacity planning, SREs and the next incident responder what to watch.

Let the reports add up. One report is a snapshot. Fifty reports with consistent metrics are a capacity history. They show how p95 drifted over a year, which releases cost headroom, and whether last quarter's fixes held. That history is only possible if every report uses the same percentiles, the same workload definitions and the same structure.

The template above is a starting point for that consistency. The goal is not a better document. It is a team that can answer "how much can we handle, and how do we know?" on any given day.

{{card}