Statping

Last reviewed Sep 13, 2026 · 740 words

The single most important fact about Statping is that the repository you land on from a search is not the one you should run. The original hunterlong/statping stopped receiving meaningful commits years ago, and the community fork at statping-ng carries the codebase forward with dependency updates and bug fixes. Run the fork, or do not run Statping at all. With that settled, what remains is a genuinely pleasant status page that fits in 128 MB of RAM, does HTTP and TCP checks well, and does not do much else.

The maintenance situation decides everything

Statping earned its 7,290 stars between 2018 and 2020 by being the prettiest self-hosted status page available: a Vue frontend, a Go backend, one binary, SQLite by default. Then development stalled. The statping-ng fork exists precisely because people still wanted that UI, and it is where releases now come from. Before you commit, read the fork's commit log yourself and decide whether the pace is acceptable for a service you will expose to the internet. My rule: a public-facing Go binary with dependencies more than a year stale is a liability, and this is the axis on which Statping loses to Uptime Kuma and Gatus, both of which ship regularly.

What it does well

Checks are simple to define: an HTTP endpoint with an expected status code and optional response regex, or a TCP host and port, on an interval you choose down to a few seconds. Each service records latency history and renders it as the sparkline charts that made the project popular. Group services, mark some private so they show only when logged in, and the public page becomes a credible status.example.com for a handful of services. Notifiers cover Slack, Discord, Telegram, email, Pushover and generic webhooks, and each one can be tested from the admin UI before you trust it. The theme editor accepts custom CSS, which is how most public Statping pages end up looking like the company's own site rather than a generic dashboard.

Deploying it takes five minutes

services:
  statping:
    image: statping/statping:latest
    ports:
      - "8080:8080"
    volumes:
      - ./statping:/app
    environment:
      - DB_CONN=sqlite
      - ADMIN_USER=admin
      - ADMIN_PASSWORD=change-me-now
    restart: unless-stopped

Swap the image for the one named in the statping-ng README before you rely on it; the original org's image is frozen. Postgres and MySQL are supported via DB_CONN=postgres or mysql with the usual host and password variables, but for fewer than 50 checks SQLite is fine and makes backup a matter of copying one directory. Put it behind your reverse proxy with TLS, because the admin login is a plain form.

Where it runs out of road

The check types stop at HTTP, TCP and ICMP. No DNS record checks, no certificate expiry alerts, no push monitors for cron jobs, no Docker container checks, no maintenance windows in the sense Uptime Kuma users expect. If your monitoring need is "is the website up and is the SSH port open", that is enough. If you want an alert when a certificate has 14 days left, you will end up running a second tool, at which point the second tool should be the only tool.

Who should still pick it

Two groups. People who already run it with a dozen checks and a themed public page: keep going on the fork, pin the version, and keep it behind the proxy. And people whose entire requirement is a nice public page for 5 to 20 services with no ambition to grow. Everyone else, including anyone monitoring a homelab with 40 containers, should read Gatus vs Uptime Kuma and pick one of those; both have moved past Statping on features and on release cadence. The status pages piece covers the public-page side, and the monitoring category lists the rest of the field.

What I'd do

New install: Uptime Kuma, not Statping, unless the look of the public page is the deciding factor and the check list is short. Existing install: move to the statping-ng fork if you have not already, pin a release tag rather than latest, keep SQLite, back up the volume nightly, and set a calendar reminder to look at the fork's activity twice a year. The day that log goes quiet is the day you migrate.