Performance & Load Testing
Run load, stress, soak, and spike tests against your endpoints and review latency percentiles, breaking points, and recovery time.
The Performance page runs tests against an HTTP endpoint and reports how it holds up. Choose a Test Type from the dropdown before running a test. Each type drives the same target with a different traffic pattern and highlights the metrics that matter for that scenario.
Test types
| Test Type | Purpose | Key Metrics | When to Use |
|---|---|---|---|
| Performance Testing | Broad evaluation of system speed, stability, and scalability. | Response times, throughput, error rates, network timing | Throughout development and before major releases |
| Load Testing | Check how the system performs under expected user or request load. | Avg. response time, concurrent users, error % | To validate everyday performance before go-live |
| Stress Testing | Push the system beyond normal limits to find breaking points. | Max load capacity, failure points, recovery time | To prepare for traffic surges or infrastructure limits |
| Soak (Endurance) Testing | Assess long-term stability under steady load. | Latency drift (a leak/degradation proxy), uptime % | For apps with 24/7 availability or long sessions |
| Spike Testing | Test reaction to sudden, extreme traffic bursts. | Response during spikes, error handling, recovery | For apps expecting peak events (sales, launches) |
Performance Testing and Load Testing run the identical constant-concurrency engine: Performance is the broad umbrella framing, Load is the everyday-validation framing, and both report the same full metric set. Stress, Soak, and Spike each run a distinct strategy, described below.
Stress Testing
Ramps concurrency upward in stages (starting from your configured concurrency, doubling each stage) until requests start failing or latency degrades sharply relative to the first stage. The results show every stage (concurrency, throughput, latency, error rate), the concurrency reached right before the breach, a plain-language description of what triggered it, and how long the target took to recover once traffic dropped back to baseline.
Soak (Endurance) Testing
Runs a constant, moderate concurrency for a long duration (up to an hour), sampled in fixed windows across the run. The results chart average latency over time and report two derived numbers: uptime % (the share of sample windows with a healthy error rate) and latency drift % (how much average latency changed from the first sample window to the last). Drift is a proxy for degradation or a memory leak on the target: this page has no access to the target's actual process memory, so rather than fabricate a number, it reports the externally observable symptom instead.
Spike Testing
Runs a short baseline warmup, a sudden burst to roughly 8x that concurrency, then samples a recovery period back at baseline. The results show baseline vs. spike average latency, the spike's error rate, and how long the target took to recover afterward.
Running a test
- Choose a Test Type. Its purpose, key metrics, and best-fit scenario are shown right below the dropdown.
- Enter the target URL and choose the method.
- Set the load options (concurrency and duration). Duration bounds adjust automatically for the selected type: Soak allows up to an hour, the others up to 5 minutes.
- Click Run Test.
KubeWatch drives the load and records the results.
Reading the results
- Configuration, the URL, method, and load settings the test used.
- Latency percentiles, p50/p90/p99 and max response times. Click a percentile for an explanation of what it means.
- Results, success and error counts. Click into the errors to see exactly what was tested, what succeeded, and what failed (by HTTP status code and transport error).
- Network Timing, average DNS lookup, TCP connect, TLS handshake, and time-to-first-byte, shown for every test type. This is the client-observable stand-in for target-side resource usage: KubeWatch is a plain HTTP client hitting a URL, so it has no visibility into the target's own CPU or memory.
- Type-specific panels: Stress shows its stage-by-stage ramp, Soak shows its latency trend chart, uptime, and drift, and Spike shows its baseline/spike/recovery phases.
- Test history, every past run, so you can compare performance across changes.
- vs. previous run, on any completed test, a comparison against the last test you ran against the same URL and method, so you can see at a glance whether a change made things faster or slower.
- Latency Trends Across Test Runs, a chart plotting p50/p90/p99/max latency across your recent test history (once you have at least 3 completed runs), plus an error-rate-vs-p99-latency correlation score so you can tell whether your errors and your tail latency tend to move together.