Statping-ng

Last reviewed Sep 13, 2026 · 771 words

Statping-ng is what you run when the status page matters more than the monitoring. Its public page is the best-looking thing you can get out of the box in this class, with grouped services, 24-hour and 7-day latency charts, and incident announcements, on a single Go binary that idles around 128 MB of RAM. As a monitor it is thinner than Uptime Kuma: fewer check types, fewer notification channels, and a slower release cadence. Choose it for the page, not for the probes.

The fork situation, in two sentences

The original Statping was abandoned by its author around 2021, and Statping-ng is the community fork that kept the code compiling and the Docker image fresh. That is honourable work, but a fork maintained by a few volunteers moves at the pace of their evenings; at about 1,990 stars it has a fraction of Uptime Kuma's following, and you should assume feature requests wait. If a tutorial points you at the original Statping, ignore it and use the -ng fork; the code is the same lineage and the fork is the only one receiving fixes.

The page is the product

Services sit in groups you order by hand, each with its own uptime bar, latency sparkline and last-failure note, and you can hide a service from the public view while still checking it. Announcements and incidents attach to a service with a timeline, which is the part a plain Uptime Kuma page does without. Theming is CSS you edit in the admin panel, and the whole page can be embedded or read through the JSON API, so a dashboard can pull the same data.

What it checks and what it cannot

Services are HTTP, TCP, UDP, ICMP, gRPC and static (a service you toggle by hand, useful for "the office printer"). HTTP checks can match a status code and a regex against the body, send a request body, and respect a timeout you set. That covers 90 percent of a homelab. What it lacks compared with Uptime Kuma: no DNS record checks, no Docker container checks, no push monitors for cron jobs, no JSON-path keyword checks, and no certificate-expiry alerting you would rely on. If your list of things to watch includes "did the backup job run", Statping-ng cannot tell you and Uptime Kuma can. Gatus is the other config-as-code option if you want checks in a YAML file rather than a database.

Notifiers are plugins: Slack, Discord, Telegram, email, Pushover, Twilio, generic webhooks, and a handful more. Webhooks are the escape hatch for anything missing.

The mobile app is a fossil

The highlights list a mobile app. It exists, it was built for the original project, and it has not moved meaningfully since the fork. Do not plan around it. The public page is responsive and reads fine in a phone browser, which is what you actually want from a status page anyway.

Install, and the database decision

services:
  statping:
    image: adamboutcher/statping-ng:latest
    ports:
      - "8080:8080"
    volumes:
      - ./statping:/app
    environment:
      - DB_CONN=sqlite
    restart: unless-stopped

That is a working single-node setup; the first visit to port 8080 runs a wizard where you name the site and create the admin user. SQLite is right for a homelab with a few dozen services. Switch DB_CONN to postgres or mysql when you have hundreds of services or want checks every few seconds, because every check writes a row and SQLite serialises writes. Back up the /app directory; it holds the database and the config file.

Run it behind a reverse proxy with TLS if the page is public, and give the status page its own hostname on a different provider from the services it reports on. A status page that goes down with the outage it is meant to describe is a common and embarrassing mistake; the status pages piece goes through the hosting choices.

What I'd do

If you need a clean public status page for a small set of services and HTTP and TCP checks are enough, Statping-ng in SQLite mode is a 10-minute job and it looks better than anything else at this size. If what you really want is monitoring, with the page as a by-product, start with Uptime Kuma; it checks more things, alerts through more channels, and has the bigger community when something breaks. I run the real monitoring elsewhere and let Statping-ng be the pretty face, which is the split it is good at.