Read run results and logs

Every Maxoperf run produces the same kinds of data: latency, throughput, errors, logs, and runner health. Reading them in the right order tells you whether a result reflects real application behavior or a test setup issue.

Read results in order

1. Confirm the run is valid. Open the Overview tab and look at 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 — status, run duration, and the headline charts to sanity-check the run before you dig in.

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

3. Read latency by label. Open the Performance tab and look at p95 and p99 by request label, not whole-run average. A slow checkout call usually hides behind fast static-asset calls in the average.

4. Open the errors tab. Group errors by status code, then by label. A spike of 503s on one endpoint is a different story from a steady trickle of 401s across many endpoints.

   

   Run detail Errors tab — group by status code or label to spot the shape of the failure.

5. Inspect error response bodies. When the error count is non-zero, see Inspect error response bodies to read the actual 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 explaining 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 — target cannot scale past this load.
Latency varies across runners	Network path or location-specific issue.

Comparing runs

Run pages support side-by-side comparison. Pick a baseline run and the new run, then open the Compare view. Latency, throughput, and error series render on the same axes so a regression jumps out visually.

For ongoing comparison across many runs, build a dashboard — see Build reporting dashboards.

Trust the data once

A clean run is the only reliable source for “what does my system do?” Once you have one good baseline, defend it — 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.