DEV Community: Antonio Cotos

Ping failed. Now what? I taught sping to investigate.

Antonio Cotos — Mon, 19 Oct 2026 15:49:09 +0000

We've all been there.

A server suddenly stops responding. Your SSH session freezes. An API becomes unreachable.

You open a terminal and run the command you've probably typed thousands of times:

ping example.com

And then...

Request timed out.

Great. Now what?

Is the server actually down? Is ICMP being blocked? Did your connection drop? Is DNS acting up? Did something change in your network?

Traditional ping tells you that packets aren't coming back.

It doesn't tell you what to investigate next.

That's the problem I wanted to tackle with the latest release of sping.

Meet sping 1.7.1

A few weeks ago, I released sping, an open-source, cross-platform network diagnostic tool written in Rust.

The original idea was simple: build a modern ping that doesn't just display packet statistics, but helps humans understand what's happening with their connections.

It already supported live latency monitoring, jitter, packet loss, quality scoring, network context, multi-target monitoring, and TCP probes.

But there was something missing.

When a connection failed, sping could show you the symptoms.

I wanted it to go one step further.

What if the tool could automatically investigate what still works when the target stops responding?

That's what version 1.7.1 introduces.

Introducing `--diagnose`

The biggest addition is a new experimental diagnostic mode.

sping example.com --diagnose

That's it.

You start monitoring your target as usual.

But when it stops responding, sping doesn't just keep displaying timeouts.

It starts gathering additional evidence.

When the target becomes unreachable, sping can automatically perform several additional checks:

IPv4 / IPv6: Can the same hostname be reached using the other address family?
TCP connectivity: Does anything answer on ports 443 or 80, even when ICMP fails?
Traceroute: How far do packets get before responses disappear?
Local network context: Does the system have a suitable source address for the destination?
DNS evidence: Did the latest hostname lookup fail or return no addresses for the requested family?

The goal isn't to magically identify every networking problem.

It's to answer a much more useful question:

"The target isn't answering. What else can we learn?"

A timeout doesn't always mean a dead server

Imagine you're monitoring a remote server.

ICMP stops responding, but TCP port 443 still answers.

That's useful information.

It doesn't prove that the application is healthy, but it tells you that something along the network path is still responding.

Or perhaps IPv4 fails while IPv6 works.

Or the trace reaches several routers before responses disappear.

Instead of jumping between ping, traceroute, and other commands, sping can collect these observations as part of the same monitoring session.

And because the diagnosis is evidence-based, it reports what was observed rather than pretending to know the exact root cause.

Your network changes. Your diagnostics should notice.

Another addition in 1.7.1 is live network context change detection.

Think about switching from Ethernet to Wi-Fi while monitoring a connection.

Or a VPN changing your default route.

These changes can completely alter how traffic reaches a destination.

sping already tracked network context, but now it can explicitly report when something changes.

For example:

context changed 00:03 ago: interface eth0 → wlan0

It can also track changes in the source address, network prefix, default gateway, and destination classification.

This is particularly useful when investigating intermittent problems.

Sometimes the interesting question isn't just whether latency increased.

It's what changed immediately before it increased.

Built for real-world troubleshooting

One thing I wanted to preserve was the simplicity of the original tool.

You can still run:

sping 1.1.1.1

And get the familiar real-time monitoring interface.

The new diagnostic mode is entirely optional.

When enabled, it only starts investigating after the target is considered offline: three consecutive failed probes, or a completed run where no replies were received.

The additional diagnostic traffic is bounded, with limits on concurrent operations and the number of extra probes.

The traceroute is also limited in time and hop count.

I didn't want a failed connection to trigger an uncontrolled burst of network traffic.

And if you're building monitoring or automation around sping, diagnostic results are also available in its structured JSON output:

sping example.com --diagnose --view json

The new active_diagnosis field exposes the additional observations programmatically.

A quick note: --diagnose is still experimental and currently supports one target at a time. Some checks depend on operating-system capabilities and permissions. On macOS, for example, the traceroute component currently supports IPv4 targets only.

A few less visible improvements

Version 1.7.1 also includes fixes and improvements across Linux, macOS, and Windows.

These include more reliable ICMP reply matching on macOS, better handling of interfaces without an address in the requested IP family, and fixes for terminal views and piped output.

They're not as exciting as a new feature, but they matter when you want a diagnostic tool you can actually rely on.

Try sping 1.7.1

sping is free, open source, and available under the MIT license.

It runs natively on Linux, macOS, and Windows.

If you have Rust installed:

cargo install sping

On macOS with Homebrew:

brew install LambdaBytes/tap/sping

On Windows with Scoop:

scoop bucket add lambdabytes https://github.com/LambdaBytes/scoop-bucket
scoop install lambdabytes/sping

Prebuilt binaries and Debian/Ubuntu packages are also available.

GitHub: https://github.com/LambdaBytes/sping

Latest release: https://github.com/LambdaBytes/sping/releases/tag/v1.7.1

Full changelog: https://github.com/LambdaBytes/sping/blob/main/CHANGELOG.md

What's next?

I'm continuing to develop sping with a simple philosophy:

Network diagnostics should help you understand problems, not just display numbers.

There's still plenty to improve, especially around automatic diagnostics, network context, and making the results easier to interpret.

And that's where feedback from people actually using the tool becomes incredibly valuable.

If you work with networks, servers, infrastructure, or simply spend too much time debugging connectivity issues, I'd love to hear what you think.

What does your troubleshooting workflow look like when ping stops responding?

What would you want a diagnostic tool to check automatically?

Feel free to open an issue, share an idea, or contribute on GitHub.

And if this is your first time hearing about sping, you can also check out my original introduction to the project.

Thanks for checking it out!

⭐ sping on GitHub

Built with Rust. Made for humans.

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

Antonio Cotos — Sun, 04 Oct 2026 00:36:20 +0000

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