Pair load tests with live observability

Aggregate RPS is where a useful load test starts. A run can hit its target throughput and still be unsafe to ship if p99 latency spikes, a small group of endpoints fails, or the runners themselves are saturated.

MaxoPerf treats a run as a source of signals, with pass/fail as one of them. The console shows latency curves, error facets, logs, and runner health together, so your team can explain the result.

Watch the test and the target

During a run, watch both sides of the system:

• Traffic shape: virtual users, request rate, throughput, and ramp phase.
• User experience: median, p95, and p99 latency for the labels that matter.
• Correctness: HTTP errors, assertion failures, and error messages.
• Runner health: CPU, memory, network pressure, and runner logs.
• Operational impact: synthetic checks, alerts, and service dashboards for the target.

This keeps you from blaming the wrong side. If the target is healthy and the runners are exhausted, add capacity or adjust the profile. If the runners are healthy and p99 latency climbs, the application needs work.

Use labels to debug faster

Flat averages hide the endpoint that breaks the release. Label your scenarios so you can read checkout, search, login, ingestion, and background workflows separately. When a regression shows up, compare the affected label with a previous run instead of combing through the whole result.

Keep the decision attached to the run

A load test should answer a release question: can we ship, should we cut scope, or do we need to fix capacity first? Keep notes, tags, and run comparisons next to the result, so the next person on the team can see the decision without piecing it together from chat.