Your launch‑day traffic,
before launch day.
Describe your users. Stampede becomes a thousand of them, and shows you exactly where your product breaks.
Find the breaking point. Fix it. Prove it.
ShopLab ships with Stampede: a small shop API with six performance problems planted on purpose. This is real output from one laptop, the same breakpoint scenario before and after turning the fixes on.
$ stampede run breakpoint.yaml requests 17302 failed 0 (0.00%) latency p50 9.51ms p95 28.6s✗ http.p95 < 250ms observed 28.57s breakpoint targets held up to 483/s, failed at 700/s knee p95 latency rose sharply
$ stampede run breakpoint.yaml requests 97220 failed 0 (0.00%) latency p50 1.70ms p95 60.5ms✓ http.p95 < 250ms observed 60.5ms breakpoint targets held up to 1567/s, failed at 1783/s
Reproduce this on your machine → About ten minutes with Docker; your numbers will differ with your hardware.
stampede init works out what kind of app it is pointed at and checks every journey once; stampede run then puts it under load and checks the targets.
stampede opens a console that stays open until you leave: every command as /command, plain language, saved sessions.
stampede run -o report.html.
more retail conversions from a mobile site just 0.1 seconds faster.
Source: Deloitte for Google, “Milliseconds Make Millions”, 2020lower conversion rates from a 100-millisecond delay in page load.
Source: Akamai, State of Online Retail Performance, Spring 2017what one hour of downtime costs over 90% of mid-size and large enterprises.
Source: ITIC 2024 Hourly Cost of Downtime SurveyThe problem
Load generators are good at sending traffic. The hard parts are everything around it: writing journeys that actually work, and trusting the numbers that come back.
| The hard part | What Stampede does |
|---|---|
| Writing journeys that work | Weighted journeys in YAML, from a ready-made product pack, or drafted with AI (optional) from a description, an OpenAPI spec or recorded traffic |
| Finding a broken login mid-test | Every journey is dry-run with one user before it joins a load test |
| Queueing hidden in the numbers | Latency counted from when each request was scheduled to leave, as wrk2 also does (measured nightly) |
| Percentiles across many machines | Each worker's histograms are merged, never averaged |
| An overloaded load generator | Workers report their own saturation, and the verdict says generator-limited instead of blaming your app |
| Graphs to interpret | The breakpoint, the knee, and pass or fail against your targets |
Describe. Validate. Stampede.
Journeys, not requests
Write how users behave, point at an API spec, or let AI draft it. Weighted journeys, data feeders, checks and extractors in one YAML file.
One user first
Every journey runs once against your target. Broken ones are repaired or flagged before any load is sent.
Then thousands
Open or closed load models, nine traffic shapes, across as many workers as you run. Reports say where it broke and why.
Your machines. Your data.
Self-hosted and open source. Nothing leaves your network unless you point an AI provider at it, and even then recorded traffic is redacted first.
CLI, web UI, CI
One binary. stampede run needs nothing else.
stampede server
API, run manager, reports. PostgreSQL / TimescaleDB.
stampede worker × N
Connect out over gRPC from any region, start in sync, merge exactly.
A system you own
Private hosts just work. Public ones need ownership proof to go beyond low caps.
Mission control
Watch a run live in the web UI or the terminal, with the kill switch always one click away.
- Live throughput, latency percentiles, errors and users per second
- Worker health, saturation and loss marked as they happen
- Stop gracefully or kill instantly; a worker that loses the server stops by itself
- Reports in HTML, PDF, CSV, JSON, JUnit and Markdown
$ stampede run shop-mix.yaml --duration 30s PASS shoplab-mix (constant-rate, 38s, stop: completed) requests 2721 (71.4/s) failed 0 (0.00%) iterations 1500 failed 0 dropped 0 latency p50 2.97ms p95 10.6ms p99 22.9ms ✓ http.p95 < 300ms observed 10.6ms ✓ errors < 1% observed 0.00% ✓ order-history.p95 < 800ms observed 6.0ms ✓ checkout.p95 < 1s observed 5.9ms
Get started
One line installs the CLI. A second starts the full stack with the web UI.
$ curl -fsSL https://raw.githubusercontent.com/Ivan825/Stampede/main/install.sh | sh $ stampede init --target http://localhost:3000 # detects your product type, installs a pack, dry-runs every journey
$ irm https://raw.githubusercontent.com/Ivan825/Stampede/main/install.ps1 | iex$ brew install ivan825/tap/stampede # Windows:> scoop bucket add ivan825 https://github.com/Ivan825/scoop-bucket > scoop install stampede
$ stampede up # web UI on localhost:8080 · two workers · TimescaleDB# or, with the ShopLab demo: git clone the repo, then docker compose up -d --build
| Command | Does |
|---|---|
stampede init --target URL | Detects the product type, installs the matching pack, dry-runs it |
stampede run file.yaml | Runs a scenario with no server; exit 3 when a target fails |
stampede generate --from-openapi spec.yaml | Drafts journeys with AI and proves each one works |
stampede compare --a ... --b ... | Judges two versions with confidence intervals; exit 4 on regression |
stampede | Opens the terminal console: /run spike, /kill all, plain language |
Every test type, one engine
Do the journeys work at all?
How does it behave at normal traffic?
What happens past the expected peak?
Does it survive a sudden jump?
Do leaks show up over hours?
At what load does it fail?
What does each extra increment cost?
How fast does it recover from overload?
Does it cope with repeated peaks?
Journeys at scale
Weighted mix Shipped
Browse 60%, search 20%, checkout 5%, with branches such as abandoned carts.
Dry-run validation Shipped
Every journey proven with one user, by hand or by the AI pipeline.
Product packs Shipped
Ready-made journeys, stresses and targets, detected by stampede init.
Endpoint coverage map Shipped
Which endpoints in your spec no journey touches, with stampede coverage.
Drift detection Shipped
stampede drift flags journeys an API change broke, by spec diff and dry run.
What you can test
Packs are folders of journeys for one kind of product. A pack is marked shipped only when it passes against a reference app in CI.
The herd is ready.
Clone it, run it, find out where your product breaks before your users do.
Run it locally ↗