httpstat: Visualizing HTTP Request Latency One Color at a Time
Hook
Most developers debug slow API calls by squinting at curl’s verbose output or adding print statements. What if you could see exactly where every millisecond goes—DNS lookup, TCP handshake, TLS negotiation, server processing—all color-coded in your terminal?
Context
When an HTTP request takes three seconds to complete, where did those three seconds actually go? Was it DNS resolution talking to a distant nameserver? A sluggish TCP handshake across continents? An expensive TLS negotiation with an overworked certificate authority? Or is your API server just slow?
Curl has always offered verbose output with the -v flag, and you can extract timing data with --write-out, but interpreting the results requires manual formatting and mental arithmetic. The Python httpstat by reorx solved this visibility problem with a beautiful, color-coded breakdown of HTTP request phases. Dave Cheney’s Go implementation takes that concept and packages it as a zero-dependency binary that runs anywhere Go compiles. As the description states, it’s like curl -v, with colours. It’s not trying to replace curl’s Swiss Army knife feature set—it’s laser-focused on answering one question: where does the time go in an HTTP request?
Technical Insight
httpstat’s value comes from visualizing HTTP request timing phases in an immediately understandable format. When you make a request through httpstat, it appears to capture timestamps at critical moments in the HTTP client lifecycle and presents them as color-coded output.
The tool presents timings that map to the physical journey of your request: DNS lookup time (how long to resolve the hostname), TCP connection time (network latency to the server), TLS handshake time (certificate exchange and encryption setup), server processing time (waiting for the first byte of response), and content transfer time (downloading the response body). Each phase is color-coded, making bottlenecks immediately obvious.
Because httpstat is written in Go and compiles to a single static binary, distribution is trivial. No Python runtime, no dependency management, no virtual environments. You install it with go install github.com/davecheney/httpstat@latest (requires Go 1.20 or later) and you’re done. The binary works on Windows, BSD, and Linux without modification.
The tool supports common HTTP client needs: custom methods with -X METHOD, request headers with -H 'Name: value', request bodies with -d string or -d @filename for file uploads, redirect following with -L, and skipping certificate validation with -k for self-signed certificates. It respects HTTP_PROXY and HTTPS_PROXY environment variables (including lowercase variants), making it corporate-firewall friendly. You can also supply client-side certificates with -E cert.pem.
What httpstat deliberately omits is also notable. The response body is discarded by default unless you save it with -o filename or -O (using the server’s suggested filename). For timing the request without downloading the body, use -I. This design reflects the tool’s purpose: you’re here to measure request performance, not to consume API responses. If you need the response body for scripting, you’re probably using the wrong tool—reach for curl or httpie instead.
Gotcha
httpstat is intentionally closed to new features. The README explicitly states ‘this project is closed’ with the exception of issue #5. Pull requests must include a fixes #NNN or updates #NNN comment and require discussion on an accompanying issue before submission. If you’re looking for a tool that will grow to accommodate new features, this isn’t it. The project maintainer has drawn a clear line about the scope.
The discarded response body is a source of confusion for developers transitioning from curl. When you run httpstat https://api.example.com/users, you won’t see the JSON response in your terminal. You’ll see timing statistics. If you need the response, add -o response.json to save it. This behavior makes sense for the tool’s purpose—measuring request performance—but it violates the principle of least surprise for users expecting curl-like behavior.
For complex HTTP scenarios, httpstat’s simplicity becomes a limitation. There’s no support for advanced features beyond what’s documented in the README: basic HTTP methods, headers, request bodies from strings or files, redirects, proxy support, and certificate handling. If you’re testing a multi-step OAuth flow or debugging a stateful API session, you’ll need to script multiple httpstat invocations and manually manage tokens, which defeats the purpose of a quick diagnostic tool.
Verdict
Use httpstat if you’re diagnosing performance issues in HTTP requests and need to quickly identify whether latency lives in DNS resolution, network connectivity, TLS negotiation, or server processing. It’s perfect for investigating why a particular API endpoint feels slow, testing CDN performance across regions, or validating that your TLS configuration isn’t adding unnecessary overhead. The visual breakdown is invaluable when you need to communicate performance bottlenecks to teams who don’t live in curl’s man pages. Skip httpstat if you need a general-purpose HTTP client for scripting, automation, or complex request flows—curl remains unbeaten for feature breadth. Also skip it if you want a tool that will evolve with new features; this project is intentionally closed to expansion. For one-time performance diagnostics with instant visual clarity, httpstat is exactly the right tool. For everything else, it’s the wrong hammer.
