Key takeaways
- A load testing dashboard earns its place by answering one question fast: did this run pass, and if not, where is the problem?
- Show percentiles next to the average, never the average alone.
- Put error rate, throughput and concurrent users on the same time axis as response time.
- Break results down by location and compare each run with a baseline, or a slow region and a slow release stay invisible.
What should a load testing dashboard show?
A good load testing dashboard shows the few numbers that decide whether a release can go out: response time as percentiles, error rate, throughput, the number of virtual users when each of them changed, results per location, and the same figures from an earlier run. Everything else is detail you open on demand. Most dashboards fail not because they lack charts but because they show the average, hide the errors and give no reference point to judge a number against.
| Question the team asks | What the dashboard needs to show | Why |
|---|---|---|
| Is it fast enough for most users? | p90, p95 and p99 response time, plus the median | The average hides the slow tail |
| Is it correct under load? | Error rate over time, grouped by response code | A fast error is still an error |
| How much work did it get through? | Requests per second (throughput) | Shows whether the system kept up or plateaued |
| When did it start to hurt? | Response time and errors against concurrent virtual users | Points to the load level where the curve bends |
| Is one region worse? | The same metrics per test location | A global average can bury one slow location |
| Is this better or worse than last time? | The same run compared with a baseline or the previous runs | A number alone has no meaning without a reference |
| Can the pipeline decide? | A pass or fail verdict against thresholds | Nobody should read charts to gate a deploy |
Why percentiles belong on the first screen
The average response time is the number dashboards show first and the one that misleads most. Google’s SRE book gives the standard example: a service with a 100 ms average latency at 1,000 requests per second can still have 1% of requests taking 5 seconds (sre.google, Monitoring Distributed Systems). Those slow requests are rare enough to leave the average almost untouched and common enough that many users hit them, especially when one page load calls several backends.
So the first screen should carry at least the median and a high percentile (p95 or p99), with the average as context. LoadFocus’s own documentation says the same: the average is fine for a quick overview and for comparing versions, while p90, p95 and p99 show how the slower share of requests behaves (loadfocus.com docs, Decoding Average Response Time). For the worked arithmetic, see why percentiles are more useful than averages, and for the definition of the measurement itself, what response time means in performance testing.
Error rate and response codes
A dashboard that shows latency without errors rewards the wrong behavior: a service that starts returning 503 quickly looks faster. Error rate belongs on the same chart as response time, with the response codes broken out so a 429 from a rate limiter is not confused with a 500 from a crashing service. A useful view also shows when the errors started and how many virtual users were active at that moment, because that ties the failure to a load level instead of a guess.
Throughput and concurrency in one view
Throughput (requests per second) answers a different question from response time. When virtual users keep rising but throughput stops rising, the system has reached its limit even if no error has appeared yet, and response time is the symptom that follows. The two metrics move together by construction, which is why throughput and response time are related in every load test. A chart of response time against virtual users makes the knee in that curve visible at a glance, and it is the chart most worth looking at after a ramp-up test.
Results per region
When load comes from several locations, a single blended number hides geography. A CDN misconfiguration, a distant database replica or a congested network path shows up as one location standing out while the others look fine. A dashboard for a multi-region test should show samples, response time, error rate and requests per second per location, and mark the worst one, so nobody has to export data to find it.
Trend against a baseline
A response time of 480 ms means nothing until you know what it was last week. The most useful context a dashboard can add is a baseline: one run marked as the reference, and every later run compared with it. Pass and fail thresholds make the same idea machine-readable: a maximum p95, a maximum error rate and a minimum throughput, checked automatically at the end of each run. LoadFocus sets one run as the baseline and compares every other run of the same test against it. Keep one caution in mind: compare full results rather than the summary alone, because averages can stay flat while the tail gets worse.
What the LoadFocus results page shows
This section describes the product as its documentation and product pages present it on 2026-10-23.
- Overview tiles: samples, average response time, 90% response time, hits per second, total errors and error percentage, with an endpoint dropdown to look at one request at a time.
- Charts: response time over virtual users, and hits per second with errors over time. The load testing page also lists the 50th, 90th and 99th percentiles, latency and standard deviation among the metrics.
- Stats tab: a per-label table with samples, mean, hits per second, minimum and maximum, the 50/90/95/99 percentiles, error counts and percentages, and sent and received KB per second, with CSV export.
- By location: when a test runs from more than one location, a table of samples, average and maximum response time, error rate and requests per second per location, with the slowest average highlighted.
- Thresholds and verdict: optional limits for maximum p95, maximum p99, maximum error rate and minimum throughput. A PASS or FAIL badge appears on the overview, each check lists its actual value and target, and a Trend tab plots p95, error rate and throughput across recent runs with the thresholds drawn on the charts.
- Baseline comparison: you mark one run as the baseline and later runs of that test are compared with it (the product page lists this from the Essential plan).
- Sharing and export: a finished run can be shared as a read-only public link, and the results page has a print-to-PDF report and a CSV export of the stats table.
- AI analysis: after a run, an AI-generated summary of the results in plain language. The free plan includes a limited number of analyses per 30 days, per the product page.
Details and screenshots are in the docs on checking load test results and pass/fail thresholds. The product itself is on the load testing page.
Signs a dashboard is working against you
- It opens on the average and needs a click to find a percentile.
- Errors live on a separate screen from response time.
- There is no reference run, so every number needs someone’s memory to interpret.
- Results from several locations are blended into one line.
- The only way to share a result is a screenshot or a spreadsheet export.
- A pipeline cannot read the verdict without a person looking at a chart.
What a dashboard cannot do
A dashboard shows what happened; it does not decide what is acceptable. If the team has not agreed on a target such as a p95 under a set number of milliseconds and an error rate under a set percentage, even a clear dashboard produces an argument instead of a decision. AI summaries help with reading, but they work from the same metrics, so a test that never exercised the slow path will not be rescued by a better view of it. Define the thresholds first, then let the dashboard report against them.
Frequently Asked Questions
What is the most important metric on a load testing dashboard?
There is no single one, but the first screen should combine a high percentile response time (p95 or p99), the error rate and throughput. Response time alone can look healthy while errors climb, and throughput alone cannot say whether users were served quickly.
Why not just show the average response time?
Because a small share of very slow requests barely moves the average. A service can have a low average and still make a noticeable fraction of users wait many seconds. Percentiles expose that tail, so show them beside the average.
How do I tell whether a result is good or bad?
Compare it with something: a baseline run, the previous release, or a pass/fail threshold the team agreed in advance. A number with no reference cannot be judged.
Do I need results per region?
If load comes from more than one location, yes. A per-location breakdown shows whether one region is slower or more error-prone than the rest, which a combined figure hides.
Can a pipeline use the dashboard?
A pipeline should read a verdict, not a chart. Set thresholds, and have the build step check the pass or fail result of the run.
Sources
- Google SRE book, Monitoring Distributed Systems (sre.google, read 2026-10-23)
- LoadFocus docs: checking load test results (read 2026-10-23)
- LoadFocus docs: results by location (read 2026-10-23)
- LoadFocus docs: decoding average response times (read 2026-10-23)
- LoadFocus docs: pass/fail thresholds (read 2026-10-23)
