Load testing & golden signals

A load test answers a different question from a functional test: not "does it work?" but "does it still work under pressure, and where does it stop?" BugBrain runs many concurrent requests at one saved API request, then organizes the results around a model the industry already trusts — the Four Golden Signals — so the report is consistent and easy to reason about regardless of which endpoint you tested.

The Four Golden Signals#

The Four Golden Signals are a standard way to describe the health of a service under load. BugBrain maps every load-test result onto them:

• Latency — how long requests take to complete. Reported as percentiles so you see the typical case and the slow tail, not just an average.
• Traffic — how much demand is hitting the endpoint, measured as throughput (requests per second).
• Errors — the rate of requests that failed or returned an error response. A system can be fast and still be quietly failing.
• Saturation — how full the system is getting: the signs that it's approaching its capacity, such as latency climbing and errors appearing as load rises.

Looking at all four together tells a complete story. Latency alone can look fine while errors spike; traffic alone says nothing about whether the service kept up. The four signals are the lens BugBrain's analysis uses to find the real bottleneck.

Latency percentiles and SLA thresholds#

Averages lie about performance, because a few very slow requests get washed out by many fast ones. BugBrain reports latency percentiles instead:

• p50 — the median. Half of requests completed faster than this.
• p95 — 95% of requests completed faster than this; the remaining 5% were slower.
• p99 — 99% completed faster; this exposes the slow tail that hurts your least-lucky users.

On top of the numbers, you can define SLA thresholds — objective targets the run must meet, such as "p95 latency under 300 ms" or "error rate under 1%." BugBrain evaluates the run against each threshold and reports a pass or fail, turning a wall of charts into a clear, objective verdict you can gate on.

The degradation knee#

As you push more traffic at an endpoint, performance doesn't degrade evenly — it tends to hold steady and then fall off a cliff. BugBrain identifies that degradation knee: the point where latency and errors start climbing sharply for each additional unit of load.

The knee is the practical answer to "how much can this take?" Below it, the endpoint absorbs load gracefully; above it, each extra request makes things disproportionately worse. Knowing where the knee sits tells you your real headroom and where to focus optimization before it bites in production.

Related#