Statping-ng

Statping-ng packages an uptime monitor, alerting engine, and status page into an official container under twenty megabytes. Forked in 2021 to maintain the abandoned Statping project, the Go application executes synthetic HTTP, TCP, and ICMP checks against designated endpoints. It stores operational history across SQLite, PostgreSQL, or MySQL without requiring dedicated worker processes.

Why Statping-ng instead of Statuspage

Atlassian Statuspage functions as a hosted incident communication portal that aggregates service health. Because Statuspage relies on third-party monitoring tools or manual updates to change component states, reporting introduces lag between an infrastructure failure and the public announcement. Statuspage also prices by subscriber volume and team seats, restricting frequent probing behind private firewalls. Statping-ng executes health checks directly from the server hosting the dashboard, delivering sub-minute HTTP assertions, TCP socket pings, and TLS certificate verifications within private subnets without cloud relay latency.

The trade-off centers on traffic isolation during outages. Statuspage serves updates from an external global delivery network, ensuring customer traffic spikes during an incident do not overwhelm origin servers. Statping-ng combines probe execution, database writes, and frontend rendering in one process. Under rapid check intervals or heavy visitor traffic, database queries against the hits table compete directly with active health checks for CPU and disk resources. Teams needing immediate private-network probing without recurring subscriptions gain local responsiveness from Statping-ng; organizations requiring an isolated status portal that survives high volumes of public traffic during an outage need Statuspage.

What it does well

• Native Prometheus exporter: Publishes probe latencies and uptime metrics on /metrics, feeding Grafana dashboards without custom scraper scripts.
• Private network probing: Executes HTTP, TCP, ICMP, and gRPC checks inside private subnets, reaching microservices hidden from external monitors.
• Multi-channel alerting: Dispatches failure and recovery notices directly to Slack, Discord, Telegram, Mattermost, Twilio SMS, or custom webhooks.
• Flexible database backends: Runs against embedded SQLite for zero-setup deployments, or PostgreSQL and MySQL for high-frequency testing.