davecheney/httpstat: HTTP timing for the command line

What davecheney/httpstat measures that curl -v does not

curl -v tells you the request happened. It does not tell you where the time went. httpstat exists to close that gap for a single request: it prints a breakdown of the phases of one HTTP or HTTPS exchange, with colour, so you can see whether a slow endpoint is spending its budget in DNS, in the TCP handshake, in the TLS handshake, or waiting on the server.

The intended user is an engineer who is already at a terminal and wants a number, not a dashboard. The README describes the tool in one line as being like curl -v with colours, and the feature list is deliberately narrow: HTTP and HTTPS, redirects, custom methods, request bodies, extra headers, proxy environment variables, client certificates. There is no configuration file, no daemon, no output format beyond what it prints.

That narrowness is the design. If your problem is "this one URL is slow and I do not know which phase is at fault", the tool answers it in one command. If your problem is "this service is slow for 5 percent of users", it does not help, and no flag in the README makes it help.

How the timing breakdown is produced

The repository is a single main.go plus a test file, with a go.mod that declares the module github.com/davecheney/httpstat and one direct dependency, github.com/fatih/color, for the coloured output. Everything else in go.mod is indirect: go-colorable, go-isatty and golang.org/x/sys. There is no HTTP client library in the dependency list, so the request path is Go's standard net/http, which is where the phase timings come from.

That matters for interpreting the output. The phases you see are the phases the Go standard library exposes: name resolution, connection establishment, TLS handshake, the write of the request, the wait for the first byte of the response, and the transfer of the body. Because the tool is a thin layer over that stack, the numbers reflect Go's behaviour, not curl's. If you are comparing results against a curl-based script, expect the two to disagree on connection reuse and on how the TLS handshake is counted.

The README does not document the exact field names or the output format. It shows a screenshot and moves on. Treat the layout as something you read with your eyes, not something you parse.

Installing httpstat and timing your first URL

The README gives one installation route: the Go toolchain. There is no package manager instruction, no release binary download link, and no Homebrew or apt line in the documentation. The README states that httpstat requires Go 1.20 or later, while go.mod declares go 1.26.0, and the v1.3.0 release note is titled "Raising minimum Go version to 1.26". If you build from the current tree, follow go.mod and the release note rather than the older sentence in the README.

Install it into your Go binary directory:

go install github.com/davecheney/httpstat@latest

After that completes, the httpstat executable is on your PATH alongside your other Go-installed tools. Run it against a single URL:

httpstat https://example.com/

The README gives exactly this example. You should see the coloured timing breakdown for that one request, and the process exits. The response body is discarded unless you ask for it, so the tool is safe to run against a large download when you only care about the timings.

Two flags are worth knowing before you script anything. To follow redirects, add -L; without it the tool reports the redirect response and stops. To skip timing the body of the response, add -I, which the README describes as skipping the body timing. The README also lists -X METHOD for changing the HTTP method, -d string for a PUT or POST body, -H 'Name: value' for extra request headers, -o filename to save the response, -O to save it under the name the server suggests, and -E cert.pem to supply a client side certificate.

Where httpstat stops being the right tool

The tool makes one request and exits. There is no repeat count, no concurrency flag, no warmup, no percentile output, and no machine-readable format in the README. A single timing sample on a shared network is noisy, and nothing in the tool helps you distinguish signal from noise. If you need a distribution, you are writing the loop yourself and parsing coloured text, which is worse than reaching for a benchmarking tool in the first place.

There is also a governance constraint that affects long-term use. The README states that, with the exception of issue #5, the project is closed, and that pull requests must include a fixes #NNN or updates #NNN comment and be discussed on an issue first. That is a clear signal about how changes arrive. If you need a behaviour the maintainer has not chosen to add, you fork it. The repository is not archived and the last push was on 2026-09-24, so the code is current, but the contribution model is narrow by the maintainer's own description.

Finally, the README does not document rollback, version pinning or an upgrade path for the installed binary. go install writes over the previous binary, and the only version control you get is whatever you do yourself.

httpstat against curl's built-in timing variables

The obvious alternative is curl with its write-out format, which is already installed on most systems. The difference is in the shape of the work. curl gives you named variables that you assemble into a format string yourself, then post-process. httpstat gives you a rendered breakdown with no assembly step, but also no format string, so you cannot ask it for one field in isolation.

If your goal is a one-off look at where a request spends its time, httpstat is less setup. If your goal is a script that emits a stable line per request into a metrics pipeline, curl's write-out is the better fit, because the field names are yours to choose and the output is text you control. The README's own framing supports this reading: it calls the tool an imitation of reorx/httpstat and points at that project as the newer work, which is an unusually candid note about where the idea came from.

Licence, upgrades and what maintenance looks like here

The repository carries an MIT licence, declared in the LICENSE file at the top level. For most users that means the usual permissive terms: keep the copyright notice, and there is no copyleft obligation on your own code. This is a description of what the file says, not legal advice; if the licence matters to your organisation, read LICENSE and your own policy.

The dependency surface is small, which keeps upgrade cost low. One direct dependency, fatih/color, plus three indirect ones, all versioned in go.mod and locked in go.sum. There is no vendor directory. The Makefile cross-compiles release binaries for linux-386, linux-amd64, linux-arm, linux-arm64, darwin-amd64, windows-386 and windows-amd64, with the version injected through -ldflags, and it refuses to run without a VERSION variable set. That is a maintainer's release process, not a documented user installation path; the README still points users at go install.

The last push was on 2026-09-24, and v1.3.0 was released the same day. The version bump in that release is the Go minimum, which means upgrading the tool can force an upgrade of your toolchain. That is the real cost of tracking this project.

Editorial conclusion

Adopt it if you need a fast, dependency-free timing breakdown for one URL on a machine that already has a Go toolchain, and you are comfortable reading raw phase numbers rather than charts. Do not adopt it if you need repeated measurements, concurrency, percentile aggregation or a CI gate; it prints one request and exits, and the project states that pull requests are closed apart from one issue. Before relying on it, check two things yourself: that the Go version you have installed satisfies the requirement in go.mod, and that the flags you intend to script (-L, -X, -o, -E) behave the way you expect against your own endpoint, because the README lists them without describing their output.

Frequently asked questions

Official sources

1. davecheney/httpstat on GitHub
2. Issues
3. License: MIT
4. README
5. Releases