Vegeta review
Curator verified · Hands-onThe short version
Vegeta is the constant rate HTTP load tool I reach for when the question is how does this service behave at exactly N requests per second.
It is a single Go binary, reads targets from a file or stdin, holds the rate regardless of how slow the server gets, and pipes results into text, JSON, or histogram reports. Use it as a Go library when you need more. It is not for user journeys, and HTTP is the only protocol.
- Strong
- CI/CD & automation, Cost & licensing
- Adequate
- Scripting & extensibility, Scale & distribution, Reporting & analysis
- Limited
- Protocol coverage, AI features
- Best for
- You need a fixed request rate regardless of server response time
- License
- Open Source
- Pricing
- Free; MIT License.
- Deployment
- Self-hosted
- Scripting / languages
- Go
- First release
- 2014
Vegeta review: the full verdict
Hands-onWhat Vegeta is
Most micro-benchmark tools hold N connections open and hammer as fast as the server answers, which means a slow server gets less load. Vegeta does the opposite. You tell it a rate, say 500 requests per second for 60 seconds, and it sends exactly that whether the server responds in 5 ms or 5 seconds. That open-loop model is how real traffic arrives, and it is what you want when you are measuring capacity rather than raw throughput.
It is written in Go, ships as one binary, and is also importable as a library, so you can embed the attack and reporting logic into your own tooling.
In practice
Everything is a pipe. echo GET https://example.com/ | vegeta attack -rate=100 -duration=30s | vegeta report gives you latency percentiles, success ratio, and bytes in and out. Swap report for encode to get JSON, plot to get an HTML latency chart, or report -type=hist to bucket latencies. Targets files support headers and bodies per request, so authenticated APIs and POST payloads are fine. I like running two attacks against two builds and diffing the JSON in CI.
Because it does not wait for responses before sending the next request, Vegeta surfaces queueing and tail latency problems that closed-loop tools hide. When a service falls over at 800 requests per second, you see the exact rate where the p99 goes vertical.
Where it falls short
Vegeta has no scenarios. Every request in the targets file is independent; there is no correlation, no extracting a token from one response to use in the next, no think time, no ramp profile beyond running several attacks in sequence. It speaks HTTP and HTTP/2 only. There is a distributed mode using multiple machines and merging results, but you orchestrate it yourself with pdsh or similar. Reports are for engineers, not stakeholders. And the maintainer community is small, so releases are infrequent.
AI features
None, and nothing is planned as far as I can see. It is a focused CLI and a library, and that is fine.
Bottom line: when you need to know how a single HTTP service behaves at a precise request rate, Vegeta is the most honest tool in this catalog. For user flows, ramps, and shareable reports, use k6 or JMeter and keep Vegeta for capacity checks.
Scorecard
Qualitative, 7 dimensionsStrong, Adequate, or Limited on each dimension. No numeric scores and no averaging, because a Limited rating on the one dimension you depend on outweighs any total.
How we rate: methodology. Ratings are refreshed with each hands-on pass, not on a fixed schedule.
Pros & cons
What stood out during testing, and what got in the way.
Pros
- Constant rate, open-loop load that mirrors real traffic
- One static Go binary and a library API
- JSON and histogram reports pipe into any tooling
- Reveals tail latency that closed-loop tools hide
Cons
- No correlation, think time, or user journeys
- HTTP only
- Distribution is do it yourself
- Infrequent releases
Who it's for
A ten-second answer for teams shortlisting tools.
Pick Vegeta when
- You need a fixed request rate regardless of server response time
- Capacity planning for a single HTTP or HTTP/2 service
- You want to embed load generation in your own Go tooling
Skip Vegeta when
- Tests need correlation, think time, or multi-step journeys
- Non-HTTP protocols are involved
- Stakeholders need dashboards and trend reports
Getting started
Minutes to first scriptMinutes; the man page is the whole manual.
Review FAQ
Answer-shapedIs Vegeta worth it in 2026?
Vegeta is the constant rate HTTP load tool I reach for when the question is how does this service behave at exactly N requests per second. It is a single Go binary, reads targets from a file or stdin, holds the rate regardless of how slow the server gets, and pipes results into text, JSON, or histogram reports. You need a fixed request rate regardless of server response time
When should you pick Vegeta?
You need a fixed request rate regardless of server response time Capacity planning for a single HTTP or HTTP/2 service You want to embed load generation in your own Go tooling Together, these are the clearest signals that Vegeta fits the project.
When should you skip Vegeta?
Tests need correlation, think time, or multi-step journeys Non-HTTP protocols are involved Stakeholders need dashboards and trend reports Treat these constraints as reasons to compare alternatives before committing to Vegeta. Compare the current documentation, operating model, and total cost with the project requirements before making a final decision.
Does Vegeta have AI features?
None by design. Check the current product documentation before relying on these capabilities in production. Compare the current documentation, operating model, and total cost with the project requirements before making a final decision.