Read run results and logs

Every Maxoperf run produces the same kinds of data: latency, throughput, errors, logs, and runner health. Read them in the right order and you can tell whether a result shows real application behavior or a problem with the test setup.

Read your test results.

Read results in order

1. Confirm the run is valid. Open the Overview tab and check runner health and run duration. If runners were saturated or the run ended early, treat the rest of the result with caution.

   

   Run detail Overview tab. Check the status, run duration and headline charts before you read further.

2. Check throughput. Did the run reach the load profile you asked for? If real throughput was lower than the planned profile, the bottleneck is upstream: the runners, the network, or the target itself.

3. Read latency by label. Open the Performance tab and check p95 and p99 per request label, not the whole-run average. In the average, fast static-asset calls usually hide a slow checkout call.

4. Open the Errors tab. It sits right after Request stats and shows the error count in its label, for example Errors (1.2K). If a notice on the Overview says your target may be blocking MaxoPerf traffic, fix that first: the errors are mostly 403 or 429 responses from a WAF or rate limiter, not application bugs. By error type shows which kinds of failure dominate; By transaction shows which requests fail. A spike of 503s on one endpoint means something different from a steady trickle of 401s across many endpoints.

   

   Run detail Errors tab.

5. Inspect error response bodies. When the error count is non-zero, see Inspect error response bodies to read the response the target returned.

6. Read logs. Runner logs show what the engine did. Use them to confirm script behavior, see assertion failures, and find data-binding issues.

7. Record a decision. Tag the run as baseline, regression, or experiment, and add a note that says what changed. Future comparisons depend on it.

Latency vs throughput vs errors

Symptom	Likely cause
High latency, low error rate	Target is slow under load but still responding.
Low latency, high error rate	Target is rejecting requests early (often auth, rate limits).
Latency rises with throughput	Capacity ceiling: the target cannot scale past this load.
Latency varies across runners	Network path or location-specific issue.

Comparing runs

You can compare runs side by side. Pick a baseline run and the new run, then open the Compare view. Latency, throughput, and error series share the same axes, so a regression is easy to see.

To compare many runs over time, build a dashboard. See Build reporting dashboards.

Trust the data once

Only a clean run tells you what your system does. Once you have one good baseline, keep it and compare every new run to it.

Where to go next

• Build reporting dashboards: pin the charts your team checks every morning.
• Inspect error response bodies: see exactly what the target replied.
• Run stuck or failed: diagnose runs that did not behave as expected.