SmokePing

SmokePing is a long-running open-source network reachability monitor that probes a configurable list of targets at regular intervals and renders the results as smokey RRD graphs, where the colour band around the median latency line shows jitter and packet loss at a single glance. Built by Tobias Oetiker, the author of MRTG and RRDtool, SmokePing has been the de facto network monitoring choice for ISPs, hosting providers, network engineers, and home-lab operators for over two decades. Unlike modern observability platforms that focus on application metrics, SmokePing is laser-focused on the layer below: can my network actually reach this thing, and how cleanly?

Common Use Cases

Network engineers and SRE teams run SmokePing on a fixed vantage point — typically a VPS in a different ASN — to measure how a known location sees the rest of the internet. The smokey graphs make brownouts, route flaps, and noisy upstream transit instantly recognizable, and the long-term RRD retention catches slow degradations that minute-resolution dashboards smooth away. Hosting providers and ISPs use SmokePing to keep an honest, customer-visible record of reachability and latency to popular destinations, building a public-facing status page from the standard CGI output. Home-lab operators monitor their internet uplink, internal Wi-Fi quality, and reachability of remote family members’ services from a single instance. Multi-site organizations deploy SmokePing slaves at branch offices and aggregate the results on a central master, comparing how the same target looks from every site to localize problems. Game-server operators and broadcasters watch the stability of upstream connectivity in real time, using TCP and HTTP probes alongside ICMP to cover scenarios where ICMP is blocked or rate-limited.

Key Features

• Smokey RRD graphs that combine median latency with a jitter/loss band in a single intuitive visualization
• Multiple probe types — ICMP ping, FPing, TCP ping, DNS, HTTP, Curl, and external scripts — usable side by side in one instance
• Hierarchical target tree organized into sections, so dashboards stay readable across hundreds of probes
• Round-robin RRD storage with constant on-disk size and daily, weekly, monthly, and yearly retention out of the box
• Threshold-based alerts that fire on sustained loss or latency excursions, dispatched via email or arbitrary external scripts
• Master/slave architecture for federating probe data from remote vantage points back into a central UI
• Built-in CGI dashboard that renders graphs on demand without needing an external visualization stack
• Configurable display and probe step intervals, alert hysteresis, and per-target probe parameters
• Pluggable probe modules written in Perl, easy to extend with custom checks for proprietary protocols
• Lightweight Perl daemon plus Apache + RRDtool stack with predictable, low CPU and memory footprint
• Long-running stability — SmokePing is a maintenance-mode mature project with very few breaking changes between releases
• Read-only web UI that is safe to expose to read-only stakeholders without an authentication layer of its own

Why deploy SmokePing on Hostinger VPS

Running SmokePing on a Hostinger VPS gives you a stable, externally-located vantage point for measuring how the rest of the internet looks from a fixed network — exactly what reachability monitoring needs. Probing from a residential connection conflates ISP problems with target problems, while running on a VPS in a well-connected datacenter lets you separate the two. Dedicated CPU on a VPS keeps probe scheduling precise even under load, which matters because RRD graphs only stay meaningful when probes really do happen at the configured cadence. Persistent disk storage makes the historical RRD database durable across container restarts and host upgrades, preserving years of latency history that would otherwise have to be rebuilt. Because the SmokePing UI is read-only and consumes minimal resources, a small Hostinger VPS plan comfortably hosts hundreds of probes with headroom for additional self-hosted tooling on the same instance. Combined with Traefik-based HTTPS routing and a custom hostname, you end up with a clean, professional-looking network monitoring page that you can share with stakeholders, customers, or the rest of your team.