DEV Community: Antonio Cotos

From Ansible to AI: Automating Network Diagnostics with sping

Antonio Cotos — Thu, 22 Oct 2026 23:35:27 +0000

Imagine this: a deployment just finished, something is slow, and you have 60 machines in an Ansible inventory.

You could SSH into each one. You could run ping 60 times. You could copy terminal output into a spreadsheet and spend the next half hour figuring out which hosts actually have a problem.

Or you could turn that inventory into a machine-readable network report, filter it in a few seconds, and hand the evidence to a script—or even an AI assistant.

That's one of the reasons I built sping, a small, open-source network diagnostics CLI written in Rust.

The live terminal view is nice. But the surprising part is what happens when you stop treating ping output as text.

The trick: JSON instead of lines of ping output

A regular monitoring session can stream newline-delimited JSON (NDJSON):

sping example.com --view json

Each line is a new measurement, with fields such as rttavg, losspct, jitter, quality, trend, and—when available—network context and diagnostic findings.

For a list of machines, there's a different mode:

sping --batch hosts.txt -c 10 --view json -o fleet.ndjson

One final JSON object per target. The targets are probed in parallel, with 10 probes each. The result isn't a screenshot or an unstructured log; it's data you can filter, compare, archive, and analyze.

Here are five things you can do with it.

1. Turn an Ansible inventory into a network health report

Ansible already knows which machines exist. Let's reuse that information.

If you have an INI or YAML inventory, use ansible-inventory to resolve it into a plain host list. This example prefers ansible_host when an alias points to a different address:

ansible-inventory -i inventory.ini --list \
  | jq -r '._meta.hostvars | to_entries[] | (.value.ansible_host // .key)' \
  | sort -u > hosts.txt

sping --batch hosts.txt -c 10 --view json -o fleet.ndjson

That's your inventory transformed into a network snapshot. No agent to install on every machine, no dashboard to deploy.

If you already maintain a text file containing one IP or hostname per line, skip the Ansible step and pass it straight to --batch.

2. Show only the machines that need attention

Now for the useful part. Rather than reading everything, ask jq for machines with no replies or at least 20% packet loss:

jq -r '
  select(.sent == 0 or .received == 0 or .loss_pct >= 20) |
  "\(.target_host): \(.received)/\(.sent) replies, \(.loss_pct)% loss"
' fleet.ndjson

Suddenly, a long inventory becomes a short list to investigate.

Want to make this part of a deployment preflight? Check TCP instead of ICMP, especially on networks where ping is filtered:

status=0
sping --batch hosts.txt --tcp 22 -c 3 --view json -o ssh.ndjson || status=$?
[ "$status" -le 1 ] || exit "$status"

jq -s -e --argjson expected "$(wc -l < hosts.txt)" '
  length == $expected and
  all(.[]; .sent == 3 and .received == 3 and (.refused // 0) == 0)
' ssh.ndjson

That last command exits unsuccessfully unless every expected host answered all three TCP attempts on port 22 without a refusal.

A TCP refusal is still a network response, but it doesn't mean SSH is accepting connections. And an open TCP port doesn't guarantee a successful login. This is a connectivity gate, not an application health check.

Operational detail: sping may skip hostnames that fail DNS resolution (and warn on stderr), so compare the number of JSON records to the expected host count. The preflight above does exactly that. In batch mode, sping can also return exit code 1 when a host receives no replies; that isn't the same as a CLI/runtime error (2).

3. Compare the network before and after a change

Ever changed a firewall rule, VPN, switch, or routing policy and then wondered which machines became worse?

Keep two snapshots:

# Before the change
sping --batch hosts.txt -c 10 --view json -o before.ndjson

# After the change
sping --batch hosts.txt -c 10 --view json -o after.ndjson

Then show the hosts whose packet-loss percentage increased:

jq -n -r \
  --slurpfile before before.ndjson \
  --slurpfile after after.ndjson '
  ($before | map({key: .target_host, value: .loss_pct}) | from_entries) as $old |
  $after[] |
  select($old[.target_host] != null and .loss_pct > $old[.target_host]) |
  "\(.target_host): \($old[.target_host])% -> \(.loss_pct)% loss"
'

You can do the same with average latency or jitter. A before/after report turns a vague "the network feels worse" into something you can investigate. It's an observation from the machine running sping, not proof of what caused the change.

4. Give an AI evidence instead of a screenshot

This is the part I find especially interesting.

Don't ask an AI to guess whether your infrastructure is healthy. Give it a small, structured report with actual measurements:

jq -s '[.[] | {
  host: .target_host,
  ip: .target_ip,
  sent, received, loss_pct, rtt_avg, jitter,
  quality, trend,
  diagnosis: (.diagnosis // [])
}]' fleet.ndjson > ai-report.json

Now paste ai-report.json into an AI assistant, or pass it to a local model, with a prompt like:

Group these hosts by symptoms. Prioritize which ones I should investigate first. Highlight total loss, intermittent loss, high latency, and consistent patterns. State what the data doesn't prove. Don't assume an ICMP timeout means the server is down. Suggest the next checks, based only on the supplied measurements.

That's the workflow I find exciting:

Ansible inventory → sping → NDJSON → deterministic filters → AI-assisted triage.

The AI isn't doing the network measurements. sping is. The model helps you organize and interpret the evidence.

If hostnames or internal IP addresses are sensitive, redact them or use a trusted local model before sharing the report.

5. Drill into one suspicious host with `--diagnose`

Batch mode answers which machines deserve a closer look. For a single problematic endpoint, sping 1.8.0 has an experimental follow-up mode:

sping example.com --diagnose -c 10 --view json > incident.ndjson

When the target stops answering, sping can try additional checks: alternative IPv4/IPv6 connectivity, TCP ports 443 and 80, and a bounded traceroute. Then you can inspect the additional findings:

jq -s '.[-1] | {
  target: .target_host,
  diagnosis: (.diagnosis // []),
  active_diagnosis: .active_diagnosis,
  gateway: .gateway,
  wan: .wan
}' incident.ndjson

The distinction matters: silence isn't proof of a firewall, and a successful TCP response isn't proof that the application is healthy. --diagnose reports observations, including checks it couldn't complete. It's experimental, single-target only, and intentionally separate from --batch.

The bigger idea

I didn't want sping to be just a prettier ping.

I wanted a tool that's useful when you're looking at a terminal and when nobody is looking at the terminal: in scripts, CI jobs, inventory audits, incident reports, or an AI-assisted troubleshooting workflow.

The terminal UI is for humans. The JSON is for everything you might build around it.

sping runs on Linux, macOS, and Windows. It's open source, MIT-licensed, and doesn't require a cloud service.

A small milestone: sping is now in Debian! 🐧

Update (October 2026): sping 1.8.0 has officially joined Debian unstable (sid), thanks to the Debian Rust Team and Simon Quigley's sponsorship.

If you're running Debian sid, you can install it directly:

sudo apt install sping

You can follow the package on the Debian Package Tracker.

Want to try sping?

If you have Rust 1.88+ installed, you can get started with:

cargo install sping
sping 1.1.1.1

Or download a prebuilt binary for your platform.

If you find sping useful, feedback and contributions are always welcome. And if you like the project, a ⭐ on GitHub helps others discover it!

I'd love to hear what you'd build with it. What network check do you still run manually that should really be a script?

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

DEV Community: Antonio Cotos

From Ansible to AI: Automating Network Diagnostics with sping

The trick: JSON instead of lines of ping output

1. Turn an Ansible inventory into a network health report

2. Show only the machines that need attention

3. Compare the network before and after a change

4. Give an AI evidence instead of a screenshot

5. Drill into one suspicious host with --diagnose

The bigger idea

A small milestone: sping is now in Debian! 🐧

Want to try sping?

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

Meet sping 1.7.1

Introducing --diagnose

A timeout doesn't always mean a dead server

Your network changes. Your diagnostics should notice.

Built for real-world troubleshooting

A few less visible improvements

Try sping 1.7.1

What's next?

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

Ping, with the context you actually need

One command, several destinations

What if the server doesn't answer ICMP?

Not just something pretty in the terminal

Give it a try

5. Drill into one suspicious host with `--diagnose`

Introducing `--diagnose`