Uptime Kuma: Self-Hosted Uptime Monitoring

Uptime Kuma is a self-hosted monitoring tool that tracks the availability of your websites, APIs, and services. With over 82,000 GitHub stars, it has become the go-to open-source alternative to cloud monitoring services like UptimeRobot and Pingdom. Uptime Kuma provides a clean dashboard, flexible alerting through 90+ notification channels, and support for HTTP, TCP, DNS, Docker, and other monitoring types.

Deploy it on your VPS and monitor your entire infrastructure from a single, private dashboard.

Key Features

• Monitor HTTP(S), TCP, DNS, Docker containers, MQTT, gRPC, and game servers
• 90+ notification integrations including Slack, Discord, Telegram, email, PagerDuty, and webhooks
• Public status pages with custom domains and branding for sharing uptime with users
• Certificate expiry monitoring with configurable warning thresholds
• Multi-language dashboard with a responsive, modern interface
• Ping and response time tracking with historical charts
• Maintenance windows for scheduled downtime without false alerts
• Proxy support and authentication for monitoring internal services

Why Self-Host Uptime Kuma?

Monitor from your own infrastructure. When you self-host Uptime Kuma, your monitoring runs independently from the services it watches. Cloud monitoring services can have their own outages, leaving you blind when you need alerts most. A VPS-based monitor in a different data center gives you reliable, independent oversight.

No per-monitor pricing. Cloud monitoring services charge per check, per monitor, or per notification. Uptime Kuma has no limits — add as many monitors as you need, check as frequently as every 20 seconds, and send unlimited alerts. All free.

Private monitoring data. Your uptime history, response times, and infrastructure topology stay on your server. Cloud monitoring platforms accumulate detailed data about your services, endpoints, and availability patterns. Self-hosting keeps this operational intelligence private.

Custom alerting rules. Configure exactly when and how you get notified. Set retry counts before alerting, customize notification templates, route different monitors to different channels, and create maintenance windows — all without the feature gates of paid tiers.

System Requirements

Resource	Minimum	Recommended
CPU	1 vCPU	1 vCPU
RAM	512 MB	1 GB
Storage	5 GB SSD	10 GB SSD
OS	Ubuntu 22.04+	Ubuntu 24.04

Uptime Kuma is extremely lightweight. A single small VPS can monitor hundreds of endpoints with minimal resource usage. Storage needs grow slowly based on how long you retain historical data.

Getting Started

Deploy Uptime Kuma on your VPS using Docker Compose through Dokploy. Our guide covers setup, persistent data storage, notification configuration, and SSL.

Deploy Uptime Kuma with Dokploy →

Alternatives

• Gatus — Developer-oriented status page with health checks defined in YAML
• Statping-ng — Status page and monitoring tool with an API-first design
• Healthchecks — Cron job monitoring service that alerts on missed check-ins
• Changedetection.io — Website change detection and monitoring tool

FAQ

How often can Uptime Kuma check my services? The minimum check interval is 20 seconds. You can configure each monitor independently — critical services can be checked every 20 seconds while less important endpoints run every few minutes.

Can I create public status pages? Yes. Uptime Kuma includes a built-in status page feature where you can group monitors, add descriptions, and share a public URL with your users. Multiple status pages are supported with independent monitor selections.

Does Uptime Kuma support multi-user access? Uptime Kuma is designed as a single-user application with one admin account. For team access, share the credentials or place it behind an authentication proxy like Authelia or Authentik.

Can I monitor internal/private services? Yes. Since Uptime Kuma runs on your server, it can reach internal services, private APIs, and resources behind firewalls. You can also configure HTTP proxies for monitoring services in different network segments.

---

App data sourced from selfh.st open-source directory.