Self-Hosting Statping-ng with Docker Compose

What Is Statping-ng?

Statping-ng is a lightweight, self-hosted status page and uptime monitor. It’s the actively maintained fork of the original Statping project, which stopped development. The Docker image is only ~20MB, making it one of the lightest monitoring tools available. It monitors HTTP, TCP, UDP, ICMP, and gRPC endpoints and provides a public-facing status page, notifications, and a management dashboard.

Updated February 2026: Verified with latest Docker images and configurations.

Prerequisites

A Linux server (Ubuntu 22.04+ recommended)
Docker and Docker Compose installed (guide)
256 MB of free RAM (minimum)
1 GB of free disk space
A domain name (optional, for public status page)

Docker Compose Configuration

Create a docker-compose.yml file:

services:
  statping-ng:
    image: adamboutcher/statping-ng:v0.93.0
    container_name: statping-ng
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - statping_data:/app
    environment:
      # Database connection type: sqlite, postgres, or mysql
      - DB_CONN=sqlite
      # Uncomment for PostgreSQL:
      # - DB_CONN=postgres
      # - DB_HOST=db
      # - DB_PORT=5432
      # - DB_USER=statping
      # - DB_PASS=changeme_statping_password
      # - DB_DATABASE=statping
      # Application name shown on the status page
      - NAME=Status Page
      # Description shown on the status page
      - DESCRIPTION=Service Status Monitor

volumes:
  statping_data:

For production deployments with PostgreSQL:

services:
  statping-ng:
    image: adamboutcher/statping-ng:v0.93.0
    container_name: statping-ng
    restart: unless-stopped
    ports:
      - "8080:8080"
    volumes:
      - statping_data:/app
    environment:
      - DB_CONN=postgres
      - DB_HOST=db
      - DB_PORT=5432
      - DB_USER=statping
      - DB_PASS=changeme_statping_password
      - DB_DATABASE=statping
      - NAME=Status Page
      - DESCRIPTION=Service Status Monitor
    depends_on:
      db:
        condition: service_healthy

  db:
    image: postgres:16-alpine
    container_name: statping-db
    restart: unless-stopped
    volumes:
      - postgres_data:/var/lib/postgresql/data
    environment:
      - POSTGRES_USER=statping
      - POSTGRES_PASSWORD=changeme_statping_password
      - POSTGRES_DB=statping
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U statping"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  statping_data:
  postgres_data:

Start the stack:

docker compose up -d

Initial Setup

Open http://your-server-ip:8080 in your browser
The setup wizard walks you through creating an admin account
Set your status page title and description
Add your first service to monitor

Default admin credentials are created during the setup wizard — there are no hardcoded defaults.

Configuration

Adding Services

From the dashboard, click Services → Create Service:

Field	Description
Name	Display name for the service
Type	HTTP, TCP, UDP, ICMP, or gRPC
URL/Address	The endpoint to monitor
Check Interval	How often to check (in seconds, default 60)
Timeout	Maximum response time before marking as failed
Expected Status	HTTP status code to consider healthy (default 200)

Notifications

Statping-ng supports notifications via:

Slack
Discord
Telegram
Email (SMTP)
Webhooks
Twilio (SMS)
Pushover
LINE Notify

Configure under Settings → Notifications. Each notification channel can be tested before saving.

Custom Status Page

The public status page is automatically generated from your services. Customize under Settings:

Theme — built-in light and dark themes
Custom CSS — override any styling
Custom Header/Footer — inject HTML for branding
Domain — serve via your own domain with a reverse proxy

Reverse Proxy

Nginx Proxy Manager configuration for status.yourdomain.com:

Scheme: http
Forward Hostname: statping-ng (container name)
Forward Port: 8080
Enable SSL with Let’s Encrypt

For Caddy:

status.yourdomain.com {
    reverse_proxy statping-ng:8080
}

Reverse Proxy Setup

Backup

Back up the data volume:

docker compose stop statping-ng
docker run --rm -v statping_data:/data -v $(pwd):/backup alpine tar czf /backup/statping-backup.tar.gz /data
docker compose start statping-ng

For PostgreSQL deployments, also dump the database:

docker compose exec db pg_dump -U statping statping > statping-db-backup.sql

Backup Strategy

Troubleshooting

Status page shows “No Services”

Symptom: The public status page loads but shows no services. Fix: Ensure services are set to Public in the service settings. Private services don’t appear on the public status page.

Notifications not sending

Symptom: Notifications are configured but never fire. Fix: Use the Test button in the notification settings to verify the channel works. Check that the notification is linked to a service under the service’s notification settings. Verify your SMTP settings or API tokens are correct.

High memory usage with many services

Symptom: Container memory grows over time with 50+ monitored services. Fix: Increase the check interval for non-critical services. Use PostgreSQL instead of SQLite for large deployments — SQLite locks under concurrent writes.

Resource Requirements

RAM: ~30 MB idle (SQLite), ~50 MB with PostgreSQL
CPU: Low — minimal overhead between checks
Disk: ~50 MB for application, plus database growth based on retention period

Verdict

Statping-ng is the best choice when you need a lightweight, all-in-one monitoring and status page tool. The ~20MB Docker image and sub-50MB RAM footprint mean it runs on virtually anything, including a Raspberry Pi. It handles the common case well: monitor a handful of services, show a public status page, send alerts when something breaks.

For more advanced monitoring (custom health check conditions, DNS/SSH checks, YAML-based configuration), Gatus is the better choice. For a more polished dashboard with 90+ notification integrations, Uptime Kuma is stronger. Statping-ng sits between them — lighter than Uptime Kuma, more user-friendly than Gatus.

Frequently Asked Questions

How does Statping-ng compare to Uptime Kuma?

Uptime Kuma has a more polished UI, 90+ notification integrations, and more active development. Statping-ng is lighter (~20 MB image, ~30 MB RAM) and includes a built-in public status page. Choose Uptime Kuma for a feature-rich monitoring dashboard; choose Statping-ng for a lightweight combined monitor and status page.

Is Statping-ng still maintained?

Development is slow but the project is not abandoned. The original Statping project stopped development; Statping-ng is the community fork that continues maintenance. Updates are infrequent — if active development matters, consider Uptime Kuma or Gatus instead.

Can Statping-ng monitor internal services?

Yes. Statping-ng supports HTTP, TCP, UDP, ICMP, and gRPC monitoring. For internal services not exposed to the internet, the Statping-ng container must be on the same Docker network or have network access to the target services.

Does Statping-ng have an API?

Yes. Statping-ng includes a REST API for managing services, viewing uptime data, and integrating with external tools. The API is available at /api on your Statping-ng instance. Authentication is required for write operations.

Can I use SQLite for production?

SQLite works fine for small deployments monitoring fewer than 50 services. For larger setups, use PostgreSQL — SQLite can lock under concurrent writes from many simultaneous health checks. The Docker Compose config above includes a PostgreSQL option for production use.

Can visitors see the status page without logging in?

Yes. The public status page is accessible without authentication by default. Services must be marked as “Public” in their settings to appear on the status page. The admin dashboard requires authentication.