Your ping works. Your connection doesn't. Meet sping.

You're in the middle of debugging a connection problem.

An SSH session freezes. An API request takes forever. Someone says, "The network looks fine."

So you do what we've all done a thousand times:

ping 1.1.1.1

Packets come back. Nice.

But what did that actually tell you? Is the problem your local network, your connection to the internet, or the specific service you're trying to reach? And what about those occasional latency spikes that disappear before you can show anyone?

ping is great at answering a simple question. I wanted a terminal tool that would help answer the next question.

That's why I built sping.

Ping, with the context you actually need

sping is a free, open-source network diagnostic CLI written in Rust. It keeps the simplicity of ping, but adds live measurements and a little more awareness of what's happening around your connection.

Run it like this:

sping 1.1.1.1

Instead of scrolling lines of replies, you get a live terminal view with a pulse graph, latency, jitter, packet loss, quality scoring, and trends.

The part I find most useful isn't the graph, though. It's network context.

While checking your target, sping can also monitor your default gateway and a separate internet reference. That helps you distinguish between situations like:

• The target stops responding, but your gateway and internet reference are reachable. Start investigating the destination or the route to it.

• Your gateway becomes unreachable. Look closer to home: local connectivity, routing, or the gateway itself.

• Your gateway responds, but the internet reference doesn't. The problem may be upstream, or that reference may be unreachable.

These are clues, not magical root-cause detection. But they're a lot more useful than staring at a timeout and guessing.

One command, several destinations

Sometimes you don't want to diagnose one host. You want to see whether several things go wrong at the same time.

sping 192.168.1.1 1.1.1.1 example.com

That switches to a multi-target dashboard, so you can compare latency, loss, quality, and trends side by side. It's particularly handy when an issue comes and goes.

What if the server doesn't answer ICMP?

A failed ping doesn't necessarily mean a service is down. Some networks simply filter ICMP.

sping 1.6.0 also supports TCP connection probes:

sping example.com --tcp 443

This measures the TCP connection attempt instead of an ICMP echo. A connection refusal is still a response from the network, not proof that the application is healthy. That distinction matters when you're troubleshooting.

Not just something pretty in the terminal

I also wanted sping to be useful in scripts and automation, not only during an interactive debugging session.

sping example.com --view json

Its newline-delimited JSON output exposes measurements and structured diagnostic findings, so you can feed them into other tools without parsing a constantly changing terminal UI.

sping runs on Linux, macOS, and Windows. It's a native CLI, not a web service you need to deploy, and the project is available under the MIT license.

Give it a try

If you have Rust installed:

cargo install sping

On macOS, you can use Homebrew:

brew install LambdaBytes/tap/sping

Or grab a prebuilt release for your platform from GitHub.

Source code, releases, documentation: github.com/LambdaBytes/sping

I'm building sping because I think command-line tools can be both lightweight and genuinely helpful when something breaks.

If you try it, I'd love to know: what's the first network problem you'd use it to investigate?

Bugs, ideas, and real-world feedback are all welcome on GitHub Issues.

Website: github.com/LambdaBytes/sping
Developer: Antonio Cotos
License: MIT License

#opensource #rust #networking #linux #windows #macos #devops #sysadmin #cli