NBping: a Rust ping tool that grew a terminal UI and a Prometheus exporter

A ping tool that outgrew the name it shipped under

The project's own one line description says it all: NBping means NB Ping, a ping tool in Rust with real-time data and visualizations. The repository is MIT licensed, written in Rust, and sits at over two thousand stars with about ninety five forks and twenty two open issues. It was pushed to on 2026-08-31 and is not archived.

The recent history is a rename. Release v0.6.1, published in January 2026, carried two entries: a rename of the project from Nping to NBping, and a version bump plus project rename that landed together. The README carries a prominent notice saying the old name is deprecated and will no longer be maintained, and asking you to update bookmarks, dependencies and installation scripts.

That notice is worth taking seriously for one reason: not everything got updated. The star history badge at the bottom of the README still points at the Nping repository path, and the v0.6.1 release notes still link their comparison to a Nping changelog URL. The Cargo package name and version are already the new ones, so the published artefact matches the new name while some documentation links lag behind it. If you are writing an installation script or a dashboard link today, use NBping and check that any pinned URL still resolves.

What the tool actually does when it runs

NBping is a concurrent ping monitor. You give it one or more targets and it pings all of them on a schedule while rendering results live in a terminal interface. The usage block shows the ordinary case, four hostnames with a count of twenty and a two second interval:

nbping www.baidu.com www.google.com www.apple.com www.sina.com -c 20 -i 2

That example tells you the project is aimed at people with several things to watch at once, since the target list is a repeated positional argument rather than a single host.

The features section is short and specific: TCP ping support and IP range ping support. Those two lines are the technical identity of the project. TCP ping is the useful addition over ICMP for networks where ICMP is filtered, and IP range ping is how you sweep a subnet and get one row per address. The default behaviour is unlimited count at zero interval, which in practice means continuous monitoring until you quit.

The rendering side is where the visualisation claim comes from. The initial view defaults to graph, and the view flag accepts graph, table, point or sparkline, switchable at runtime with the number keys one through four or the Tab key. A project with a small demo animation and a banner from a Chinese open source discovery site sits at the popularity level you would expect for a tool that does one thing visually and does it in a terminal.

The flag surface, in full

The help output is short enough to read end to end, which is a good sign for a tool people are expected to operate.

The positional argument is the target list, described as an IP address or hostname to ping. Count sets how many pings to send and defaults to zero, meaning unlimited. Interval is the seconds between pings. There is a force IPv6 switch, and the help notes the same setting can be enabled from the config file instead.

The less obvious one is multiple, which caps the maximum number of target addresses and, as the help states, only works on a single target address. That is the flag behind IP range ping: you give it one range and it expands it into that many addresses. Set to zero by default, meaning no cap.

Output takes a file path for saving results. View type picks the initial rendering mode described above. And config points at a YAML file, with the help stating plainly that command line flags override its values. Version and help round it out.

One thing to note about provenance: the usage sample that appears in the README is preceded by a short user guide video credit, and the flags themselves come from the binary's own clap-based help. The dependency list in the package manifest confirms the shape of the tool: clap for argument parsing with derive, ratatui for the terminal interface, tokio with the full feature set for concurrency, pinger for the probes themselves, plus serde and a YAML parser for config.

Exporter mode and the Prometheus path

The feature that separates NBping from a nicer ping loop is an exporter mode. Instead of drawing a chart, the tool serves Prometheus format metrics over HTTP so a dashboard tool can scrape them.

nbping exporter www.baidu.com www.google.com -i 1 -p 9100

That example pings two hosts once a second and serves metrics on port 9100, which the README then tells you to scrape from the localhost metrics path. The subcommand has its own help block, described as exporter mode for monitoring, and the flags are a trimmed set: interval, port, force IPv6 and config, with port defaulting to 9090 when you do not pass one.

The Rust dependencies explain the shape of that mode more directly than the prose does. The manifest includes the Prometheus client library, hyper with its full feature set, hyper-util configured for tokio and server use across HTTP 1 and HTTP 2, and http-body-util. So the exporter is a genuine embedded HTTP server rather than a file the tool writes and a sidecar tails, and the metrics registry is a real one.

For a monitoring setup, the practical consequence is that NBping can be the thing that owns reachability data, and Grafana becomes the display. The README includes a screenshot of that arrangement. What it does not include is a list of the individual metric names, so if you are building alerts you will want to fetch the metrics endpoint once and read what is actually exported rather than guessing at label names.

Configuration precedence, stated clearly

Because the flag list is long, a config file matters, and the project documents precedence without hedging. The order is command line flag, then YAML config, then built-in default. The example given makes it concrete: starting from a config file and then passing an interval of one on the command line forces a one second interval regardless of what the file says.

The example file is commented, which is the right call for something with this many fields.

mode: tui              # tui | exporter (default: tui)
targets:
  - google.com
  - github.com

Mode selects between the terminal interface and exporter mode when no subcommand is given, while the explicit exporter subcommand always uses exporter mode regardless of what the file says. Force IPv6 has one asymmetry worth knowing: the flag can only turn IPv6 on, so if a config file enables it and you want it off, you have to set it to false in the file. Unknown keys are rejected outright, so a typo surfaces as a startup error instead of a setting that quietly does nothing.

Several fields are marked as belonging to one mode only, such as multiple, view type and output in the terminal interface, and port in exporter mode. That is a small quality signal: the config mirrors the flags, and the comments tell you where each one applies.

Separately, the repository tree also holds a Chinese README, a docs directory, and a file named CLAUDE.md. The presence of a contributor instruction file alongside a Chinese and an English README is typical of a project with a steady outside contributor base, and the acknowledgements section names seven individual contributors plus a list of Chinese-language publications and social accounts that reposted it.

What to check before you rely on it

Installation is the first gap. The documented path is a single Homebrew formula for macOS, followed by the help command to confirm. There is no documented Linux or Windows package, no cargo install line, and no release artefact list in the tree. For a platform without Homebrew, expect to build from source against the published dependencies.

The manifest itself is modest and conventional: edition 2021, MIT licence, a single named author, and a dependency set that matches the feature list with nothing exotic in it. The pinned versions suggest a project tracking upstream releases closely rather than pinning hard.

The roadmap is a single line about optimising the interface and adding more dynamic effects, which tells you where the author's attention is going. The version numbers tell you the pace: 0.6.1 in January 2026, 0.7.0 in May, 0.7.1 in June, and pushes continuing through August. A pre-1.0 tool in active development carries the usual implication, that the flag surface can change between minor versions.

One naming trap for search. Queries around the old name pull up unrelated results, and the related searches attached to this project include an Android variant and generic download terms. If you arrive looking for a mobile app or a Windows installer, you will not find one here. What exists is a terminal tool, most easily installed on a Mac, with a Prometheus mode that is the most interesting part of it.

Editorial conclusion

NBping fits a person who pings the same handful of hosts repeatedly and wants the results on one screen instead of in six terminal tabs. The flag surface is wide for a ping tool, covering count, interval, IPv6 forcing, multiple address expansion, four view modes and file output, and a config file carries the same settings with a stated precedence order. Two things to check before adopting it. First, the only installation path documented is Homebrew on macOS, so a Linux or Windows machine needs a build from source. Second, the project changed its name from Nping, and some references have not caught up, so search for both. On a Mac, run the tool against two addresses with a short count, switch view modes with the number keys, then check whether the metrics endpoint in exporter mode is something you would rather scrape from Grafana than read from a chart.

Frequently asked questions

Official sources

1. hanshuaikang/NBping on GitHub
2. Issues
3. License: MIT
4. README
5. Releases