Pair load tests with live observability

The most useful load tests do not end at aggregate RPS. A run can hit the target throughput and still be unsafe to ship if p99 latency spikes, a small endpoint group fails, or the runners themselves are saturated.

Maxoperf is built around the idea that a run should produce signals, not just a pass/fail checkbox. The console brings together latency curves, error facets, logs, and runner health so the 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 important labels.
• 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.

The goal is to avoid blaming the wrong side. If the target is healthy but runners are exhausted, add capacity or adjust the profile. If runners are healthy but p99 latency climbs, the application needs attention.

Use labels to debug faster

Flat averages hide the endpoint that hurts the release. Label your scenarios so checkout, search, login, ingestion, and background workflows can be read separately. When a regression appears, compare the affected label against 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 reduce scope, or do we need to fix capacity first? Store notes, tags, and run comparisons next to the result so the next team member can understand the decision without reconstructing it from chat.