Distributed load testing with a live dashboard
Write your test in Go or YAML, run it from one machine or fifty, and watch the results as they happen. One binary — no agent to deploy alongside it, no database to stand up, no separate UI to host.
$ tar xzf loadwave_darwin_arm64.tar.gz
$ xattr -d com.apple.quarantine loadwave
$ ./loadwave demo
dashboard on http://localhost:8088$ tar xzf loadwave_linux_amd64.tar.gz
$ ./loadwave demo
dashboard on http://localhost:8088> Expand-Archive loadwave_windows_amd64.zip -DestinationPath .
> .\loadwave.exe demo
dashboard on http://localhost:8088Download loadwave_darwin_arm64.tar.gz — or the Intel build.
Download loadwave_linux_amd64.tar.gz — or the ARM64 build.
Download loadwave_windows_amd64.zip — or the ARM64 build.
loadwave demo starts a target server of its own. Nothing to configure, nothing to stand up. See every way to install it, including why go install leaves the dashboard out.
Why another load tester
Percentiles that survive being distributed
Nodes ship whole HDR histograms rather than their own percentiles, and the coordinator merges the distributions. A p99 from ten agents is the real p99, not an average of ten p99s — which is not a number that means anything.
How aggregation works →Real processes, not just goroutines
Past a few thousand virtual users a single Go runtime's scheduler and garbage collector become the bottleneck rather than the system under test. LoadWave spreads the pool across worker processes so you keep measuring the server.
Read the architecture →Tests you can review
Behaviour is ordinary Go — conditionals, session state, custom auth — testable with `go test` against an httptest.Server, with no coordinator involved. Simple flows can stay in YAML.
Writing tests in Go →Built to be a CI gate
Thresholds are first-class, and the exit code distinguishes "the tool broke" from "your service was too slow" — two conditions that call for very different responses from a pipeline.
Using it in CI →