# Vegeta review

> 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.

- Canonical: https://perf.jmeter.ai/reviews/vegeta/
- Tool page: https://perf.jmeter.ai/tools/vegeta/
- Reviewed: 2026-09-18 · Hands-on

## Verdict
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.

### Pick it 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 it when
- Tests need correlation, think time, or multi-step journeys
- Non-HTTP protocols are involved
- Stakeholders need dashboards and trend reports

## What 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
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.

## About this review
Hands-on review: I installed the current Vegeta release, attacked local and public HTTP endpoints at fixed rates from a targets file, and compared its open-loop behaviour and reports with wrk and hey.

## Ratings
| Dimension | Level | Note |
| --- | --- | --- |
| Scripting & extensibility | Adequate | Targets files plus a Go library API; no scenario scripting. |
| Protocol coverage | Limited | HTTP/1.1 and HTTP/2 only. |
| Scale & distribution | Adequate | Very efficient per box; multi-machine runs are manual with result merging. |
| Reporting & analysis | Adequate | Text, JSON, histogram, and HTML plot outputs; no dashboards. |
| CI/CD & automation | Strong | Pipe friendly, JSON output, and exit codes make it trivial to gate. |
| Cost & licensing | Strong | MIT licensed, free. |
| AI features | Limited | None by design. |

## 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

## Getting started
- Install: `brew install vegeta`
- First run: `echo 'GET https://example.com/' | vegeta attack -rate=50 -duration=30s | vegeta report`
- Learning curve: Minutes; the man page is the whole manual.

## FAQ
### Is 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.

---
Curated by NaveenKumar Namachivayam (QAInsights) · methodology: https://perf.jmeter.ai/about/#methodology · corrections: https://github.com/QAInsights/Performance-Testing-Tools/issues/new?title=Tool%20submission%3A%20&body=Tool%20name%3A%20%0AOfficial%20URL%3A%20%0AWhat%20should%20be%20added%20or%20corrected%3F%20%0A