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!
Built with Rust. Made for humans.
Top comments (2)
Nice writeup — the ordering of the checks matters a lot in practice. One thing I'd find useful in the JSON output: distinguishing "ICMP silently dropped" from "ICMP unreachable came back", since that usually tells you whether you're looking at a firewall policy or an actual routing problem. Good call keeping the diagnostic traffic bounded too.
Thanks, Max! That’s a really good point.
Interestingly, sping 1.7.1 already makes part of that distinction in the traceroute diagnostics: active_diagnosis can report reported_unreachable (including network, host, or administratively prohibited responses..) versus silent_after.
But you’re right that the main ICMP probe doesn’t expose that distinction as clearly in its structured output yet.
I think surfacing explicit ICMP responses, including their type/code and source when available, would be a useful improvement. Especially without assuming that silence automatically means firewall filtering.
Really appreciate the thoughtful feedback.