Yes: hey natively supports duration mode and per-worker QPS limits, but the total rate must be interpreted using the worker count.

• -z sets the test duration; the README states that the program stops when the duration is reached and that -n is ignored in this mode.
• -q is measured per worker. The README example -q 10 -c 5 -z 30s exactly represents 10 QPS per worker, 5 workers, for 30 seconds.
• -c controls the number of concurrent workers, so -q is not a global rate limit.

This fits staging capacity checks and sustained-load observation. The README does not promise that the theoretical rate will be exact, nor does it provide server-side throttling, alerting, or monitoring integration; latency and scheduling can affect the achieved rate.

Yes: it directly provides concurrent workers, request counts, and summary statistics, and is positioned as a lightweight ApacheBench replacement.

• -n controls the total request count and -c controls concurrent workers; the README explicitly demonstrates -n 1000 -c 100.
• It prints summary statistics by default, covering basic throughput and latency comparisons, and can export response metrics with -o csv.
• The project is a standalone Go command-line program with Linux, macOS, and Windows amd64 binaries, so setup is lightweight.

It is not a complete performance platform: the README does not describe distributed execution, multi-step business flows, or server-side metric collection. It fits a single-URL HTTP benchmark, but more complex user journeys require another tool.

Yes: hey supports POST, custom headers, and string- or file-based request bodies, which covers this single-request template.

• -m supports POST, so the method can be set explicitly instead of using the default GET.
• -H can be repeated for multiple headers; the README demonstrates both Accept: application/json and Authorization: Bearer token.
• -d accepts a string request body, -D reads one from a file, and -T sets the Content-Type.

This is sufficient for fixed-JSON API regression, basic throughput testing, and authorization-header checks. However, the explicitly documented authentication option is Basic authentication; the Bearer token is passed as a normal header. The README does not describe dynamic token refresh, parameterized datasets, or generating a different body for every request.

Yes: it provides standalone binaries for the relevant platforms and CSV output, which is sufficient for a basic CI test step.

• The Installation section lists download URLs for Linux amd64 and macOS amd64 and also supports installation through Homebrew on macOS.
• -o csv is explicitly supported and exports response metrics for later parsing or storage.
• -n and -c make the test scale explicit in a CI command, while the default output also prints a summary.
• The project is delivered as a standalone command-line program rather than a full performance platform.

It is better suited to producing raw benchmark data than to enforcing a complete quality gate. The README lists summary and CSV output but does not describe JUnit, HTML reports, threshold assertions, trend charts, or CI plugins; those functions must be implemented in the pipeline.

Yes: hey provides a proxy address, a custom Host header, and a Linux amd64 binary, making it suitable for single-URL routing validation.

• -x accepts an HTTP proxy address in host:port form and directs requests through that proxy.
• -host sets the HTTP Host header, allowing validation of virtual-host or Host-based routing rules.
• The Installation section provides a Linux amd64 binary, so no additional platform service is required on the target host.
• -t sets the timeout for each request, while -disable-redirects prevents redirect following and helps expose the entrypoint’s original response behavior.

The README does not explain proxy authentication, HTTPS CONNECT details, SOCKS proxy support, or multi-target routing orchestration. If validation requires proxy credentials, complex certificate chains, or multi-service business flows, a single hey command cannot be fully justified from the README.

It depends: hey provides an HTTP/2 switch, but actual HTTP/2 use depends on negotiation with the target endpoint and the client environment.

• The README explicitly says hey supports HTTP2 endpoints and provides -h2 Enable HTTP/2.
• HTTP/2 tests can still use -n, -c, or -z, so concurrent and fixed-duration load models do not require a different tool.
• The project also supports custom Host headers, timeouts, proxies, and connection-behavior options, which helps with some endpoint configurations.

However, -h2 only enables the client-side option; it does not guarantee that the target processes requests as HTTP/2. The README does not describe ALPN/TLS negotiation, cleartext h2c support, HTTP/2 connection reuse statistics, or a protocol-version confirmation field. It is suitable for initiating a test, but not sufficient by itself to prove the negotiated protocol.