SolidPing

Distributed, self-hostable uptime monitoring. 40 check types, multi-region workers, private agents, status pages, incidents and on-call escalation — in a single Go binary.

Screenshots

Checks list	New-check form	Check detail

Try it

Overview

SolidPing is a multi-tenant monitoring system that enables organizations to monitor their infrastructure through distributed workers executing health checks. It's designed for low resource consumption and easy self-hosting.

Key Features

• 40 check types: HTTP, TCP, UDP, ICMP, DNS, DNSBL, NTP, SSL/Domain, SSH, RDP, FTP/SFTP, SMTP/POP3/IMAP, Email (JMAP passive inbox), WebSocket, SIP, gRPC, Prometheus, 7 databases (Postgres, MySQL, MSSQL, Oracle, ClickHouse, MongoDB, Redis), 3 message queues (Kafka, RabbitMQ, MQTT), Docker, Kubernetes, SNMP, Freebox line, game server (Source/A2S, Minecraft), headless browser, custom JS, heartbeat
• Distributed workers: Multi-region check execution with lease-based scheduling, per-region check periods with spread control, and per-org check-rate quotas
• Private locations: Deported agents run checks from inside your own network over an outbound WebSocket, with per-org agent quotas
• Multi-tenant: Organization-scoped data isolation, RBAC, 2FA (TOTP), labels with autocomplete
• Low footprint: Single binary; SQLite, embedded Postgres, or external Postgres
• Fast checks: Sub-minute frequencies supported
• Notifications (10 native): Slack (OAuth + threads + Marketplace install), Discord (OAuth + webhook), Email, Webhooks, Google Chat, Mattermost, Ntfy, PagerDuty, Pushover, Web Push (VAPID)
• Incidents: Adaptive resolution with cooldown, group-incident correlation (one alert per outage, not per check), acknowledgment, snooze, manual resolve, and per-incident comments
• Check groups: Organize checks into groups with grouped pagination and group-level incident correlation
• On-call & escalation: Rotation schedules with overrides, multi-step escalation policies (user / schedule / connection / all-admins targets, repeats)
• Credentials encryption at rest: Envelope encryption with out-of-band master key; secrets never echoed back to the dashboard
• SSH tunnels: Reach otherwise-unreachable targets through SSH jump hosts
• Status pages: Sections, resources, public availability metrics, locale-aware date formatting
• Maintenance windows: Recurring suppression of alerts
• JavaScript scripting: Sandboxed custom monitoring logic
• Browser monitoring: Headless Chrome via Rod
• MCP server: AI/LLM tool access via Model Context Protocol
• SSO / OAuth: Google, GitHub, GitLab, Microsoft, Slack, Discord, plus generic OIDC, SAML, and LDAP / Active Directory (per-provider enable toggle, with self-service token revocation)
• Observability: Prometheus /metrics, Sentry integration, OpenTelemetry
• CLI client: Manage checks and results from the terminal
• i18n: Multi-language dashboard (English, French, German, Spanish)

Quick Start

Prerequisites

• Go 1.24+
• PostgreSQL 15+
• Docker (for development)
• Bun (for frontend development)

Development Setup

# Start PostgreSQL
docker-compose up -d

# Build and run
make build && ./solidping serve

# Or use hot reload for development
make dev-test   # Backend + frontend with hot reload

Default Credentials

• Email: admin@solidping.io
• Password: solidpass
• Organization: default

Both halves of that pair are published here, so the first login on a fresh database must set a new password before the account can do anything else. The dashboard takes you straight to the form; over the API the login succeeds and every endpoint except POST /api/v1/auth/change-password, GET /api/v1/auth/me and POST /api/v1/auth/logout answers 403 with code PASSWORD_CHANGE_REQUIRED until you rotate it.

API Example

# Get a JWT token
TOKEN=$(curl -s -X POST -H 'Content-Type: application/json' \
  -d '{"org":"default","email":"admin@solidping.io","password":"solidpass"}' \
  'http://localhost:4000/api/v1/auth/login' | jq -r '.accessToken')

# List checks
curl -s -H "Authorization: Bearer $TOKEN" \
  'http://localhost:4000/api/v1/orgs/default/checks'

Supported Check Types

Network

Security & Certificates

Email

Databases

Remote Access

Message Queues

Infrastructure

Specialized

Configuration

Everything is configured with SP_-prefixed environment variables. Precedence: environment variables > config.local.yml > config.yml > defaults.

You only need the database settings to get started — the defaults cover the rest.

SQLite (the default — good for a single instance)

Nothing to configure. The image already stores the SQLite database and every uploaded blob (org logos, status-page assets, screenshots) under /data, so a single mounted named volume is enough:

docker run -p 4000:4000 \
  --hostname solidping \
  -v solidping-data:/data \
  ghcr.io/fclairamb/solidping

--hostname solidping is not optional: the worker name is derived from the hostname and must match ^[a-z][a-z0-9-]{2,20}$. Docker's default hostname is the random container ID, which starts with a digit most of the time, and the server then refuses to start. Pass --hostname, or set SP_NODE_NAME instead.

If you use a bind mount instead of a named volume (-v ./solidping-data:/data), the host directory keeps its own ownership, which is usually not writable by the image's nonroot user (uid/gid 65532). Either chown 65532:65532 the host directory first, or run with -u "$(id -u):$(id -g)". A named volume, as used above, doesn't have this problem — Docker seeds it from the image with the right ownership.

PostgreSQL (recommended for production)

Schema migrations run on first boot, so point it at an empty database and let it create its own tables:

docker run -p 4000:4000 \
  --hostname solidping \
  -e SP_DB_TYPE=postgres \
  -e SP_DB_URL='postgresql://solidping:password@postgres:5432/solidping?sslmode=disable' \
  ghcr.io/fclairamb/solidping

sslmode=disable is right for a database on the same private network, and is what a stock postgres container accepts — it serves no TLS, so sslmode=require fails against one with SSL is not enabled on the server. For a managed or remote database, use sslmode=require (or verify-full) instead.

The variables you actually need

That is the whole getting-started surface. Everything else — authentication and SSO, email and the other notification channels, custom domains and TLS, multi-region workers, data retention, storage — is optional and documented at docs.solidping.io:

Architecture

Core Components

• API Server: REST API for managing checks, incidents, and results
• Dashboard (web/dash0): Admin UI (React + TanStack Router + shadcn/ui)
• Status Page (web/status0): Public-facing status dashboard
• Workers: Distributed agents executing monitoring checks
• Notifications: Slack, Discord, Email, Webhooks, Google Chat, Mattermost, Ntfy, PagerDuty, Pushover, Web Push
• Database: PostgreSQL (partitioned results) or SQLite

Technology Stack

• Backend: Go 1.24+, go-chi/chi v5, Bun ORM, koanf
• Frontend: React 19, TypeScript, Vite, TanStack Router/Query, Tailwind CSS, shadcn/ui
• Database: PostgreSQL (production), SQLite (development/single-node)

Project Structure

solidping/
├── server/
│   ├── main.go                  # CLI entry point (serve, migrate, client)
│   └── internal/
│       ├── app/                 # Server setup, services, embedded assets
│       ├── handlers/            # HTTP handlers + business logic
│       ├── checkers/            # Protocol checker implementations
│       ├── notifications/       # Notification channels
│       ├── db/                  # Bun models + Postgres/SQLite migrations
│       └── middleware/          # Auth, CORS, org context
├── web/
│   ├── dash0/                   # Admin dashboard (React)
│   └── status0/                 # Public status page
├── docker-compose.yml           # Development PostgreSQL
├── Dockerfile                   # Production container
└── Makefile                     # Build targets

Development

Commands

make build            # Build complete application
make dev-test         # Hot-reload backend + frontend
make dev-backend      # Backend only with hot reload (air)
make dev-dash0        # Dashboard dev server
make test             # Run backend tests
make lint             # Lint all code
make fmt              # Format all code
make docker-build     # Build Docker image

CLI Client

# Build the CLI
make build-cli

# Usage
./bin/sp auth login
./bin/sp checks list
./bin/sp results list

Goals

Primary

• Many protocols and test types
• Low memory footprint
• Fast execution (sub-minute checks)
• Easy self-hosting (single binary + PostgreSQL)
• Cross-platform (Linux, macOS, Windows)
• Public status pages

Non-Goals

• Multi-step transactional / scripted user-flow testing (use Playwright directly for that)
• Application Performance Monitoring / RUM (use Datadog, New Relic, or Site24x7)

Inspiration

• uptime-kuma - Great self-hosted monitoring tool

Contributing

Bug reports and pull requests are welcome — see CONTRIBUTING.md for local setup and PR conventions. Found a security issue? See SECURITY.md rather than opening a public issue.

License

AGPL-3.0 - See LICENSE.