When a service starts misbehaving, my first reflex is ping. It tells me almost instantly whether the box is up, whether latency is sane, and whether anything weird is going on at the network layer. The trouble is that for HTTP services, ping answers the wrong question. The host can answer ICMP just fine while the application returns 502s every other second.

httping-go is my Go take on the classic httping idea: a tiny CLI that hits a URL on a loop and prints status code, latency and response size. It’s the tool I reach for when I want a quick, continuous feel for how an HTTP endpoint is behaving.

What it does

You point it at a URL and it loops, one request at a time, until you Ctrl+C:

$ httping -u https://www.github.com -s 500
connected to https://www.github.com, seq=1 time=761.159 bytes=206779 StatusCode=200
connected to https://www.github.com, seq=2 time=147.326 bytes=206779 StatusCode=200
connected to https://www.github.com, seq=3 time=143.971 bytes=206779 StatusCode=200
connected to https://www.github.com, seq=4 time=138.060 bytes=206779 StatusCode=200
^Csignal: interrupt

That’s the whole interface. Two flags:

httping:
  -u string   url to "ping"
  -s int      time to sleep between two tries (default 200, in ms)

You read the output the same way you read ping output: watch the cadence, watch latency, watch the status code. Anything that’s not a steady stream of 200s is a problem.

Why I keep it on every machine

A few situations where it earns its place over curl or a browser:

  • Catching intermittent failures. A flaky load balancer that drops one request out of fifty is invisible to a single curl. Twenty seconds of httping makes it obvious.
  • Watching a deploy. Running httping -u https://service.example.com/health while a rolling deploy goes through is the cheapest sanity check there is.
  • Latency vibes. I don’t need a Grafana dashboard to know whether a service feels slow. Five seconds of httping and I know.
  • Cold cache demonstrations. The first hit is slow, the next ones are fast — this is visible at a glance, no thinking required.

It’s the same instinct as classic ping, applied at the layer that actually matters for web services.

Installing it

Two paths. From source:

go install github.com/sgaunet/httping-go@latest

Or grab a prebuilt binary from the releases page and drop it into your $PATH. There’s also a Taskfile in the repo — task -w run rebuilds and re-runs on source changes if you want to hack on it.

A few usage patterns

Tighten the loop when you’re hunting fast-recovering issues:

httping -u https://api.example.com/health -s 50

Loosen it for long-running watch jobs that you don’t want to flood:

httping -u https://api.example.com/health -s 5000

Pipe it through grep when you only care about non-200 responses (and you’ve left it running for a while):

httping -u https://api.example.com/health | grep -v 'StatusCode=200'

That last one has saved me real time. Leave it running in a tmux pane while you investigate something else; come back, see the failures lined up.

Scope and honesty

httping-go is intentionally tiny. It doesn’t do TLS handshake timing, header validation, percentile reporting, or anything fancy. If you need that, look at vegeta or hey. What this tool gets right is being available immediately, on any machine, for the boring “is this URL OK right now?” question.

It’s MIT-licensed, the code is small enough to read in one sitting, and it lives at github.com/sgaunet/httping-go. If you spend any time staring at HTTP services that may or may not be misbehaving, give it a try — it might earn a permanent spot in your toolbox.