Uptime Kuma (Self-Host Monitoring)

Open-source self-hostable uptime monitor (UptimeRobot alternative) with HTTP/TCP/ping/DNS checks, status pages, and notifications.

VPS & Self-HostedBeginner

Why

Uptime Kuma is a single-container uptime monitor with a polished UI, 70+ notification integrations (Slack, Discord, email, PagerDuty), and public status pages. Self-hosting avoids UptimeRobot's limits and keeps monitoring data private.

It supports push monitors for cron jobs and certificate-expiry alerts.

When

Use Uptime Kuma to monitor your self-hosted services, external APIs, and TLS cert expiry. Run it on a different VPS than the services it monitors (so a monitored-host outage does not take down the monitor).

Free and unlimited.

How

1. Run the Uptime Kuma container with a named volume. 2. Open the UI at port 3001 and create an admin account. 3. Add monitors: HTTP (URL), TCP (host:port), Ping, DNS, or Push. 4. Set check interval and retries. 5. Configure notifications (Slack webhook, email SMTP, etc.). 6. Create a public status page if desired. ```bash docker run -d --restart=always --name uptime-kuma \ -p 3001:3001 -v uptime-kuma:/app/data \ louislam/uptime-kuma:1 ```

Example

// vps-uptime-kuma — configuration example const config = { provider: "vps" }; Add an HTTP monitor with a Slack notification and a public status page: 1. Settings > Notifications > Slack > add webhook URL > test > save. 2. Add New Monitor > HTTP(s) > URL: https://app.example.com/health > interval 60s > enable notifications. 3. Add a certificate monitor: type "Certificate" > domain app.example.com > alert if expiry < 14 days. 4. Status Pages > New > add monitors > set slug "public" > share https://status.example.com. Push monitor for a cron job (the job pings the URL each run): ```bash # in your cron job, after success: curl -fsS "https://kuma.example.com/api/push/AbCd123?status=up&msg=OK&ping=42" ```

Common Problems

⚠Monitor shows down but site is up — the monitor's expected status code or keyword filter is too strict; check the monitor's 'Keyword' and 'Accepted Status Codes' settings.
⚠Notifications not firing — the notification channel test failed silently; re-test in Settings and check the webhook URL / SMTP credentials.
⚠Configuration drift between environments — use infrastructure-as-code (Terraform/Pulumi) to keep dev/staging/prod identical

Best Practices

✓Run Uptime Kuma on a different host than the services it monitors, so a single-host failure does not blind your monitoring.
✓Use push monitors for cron jobs and backups — the job pings Kuma on success, and Kuma alerts if the ping stops (job hung or failed).
✓Add a certificate-expiry monitor for every TLS endpoint so you are alerted 14 days before expiry, not on the day it breaks.

FAQ

What is Uptime Kuma (Self-Host Monitoring) and what problem does it solve?

Open-source self-hostable uptime monitor (UptimeRobot alternative) with HTTP/TCP/ping/DNS checks, status pages, and notifications. It lets developers deploy, store, and scale without self-managing infrastructure — a core reference for cloud service selection.

How do I get started with Uptime Kuma (Self-Host Monitoring) in 5 minutes?

Two steps to run it: (1) Run the Uptime Kuma container with a named volume.; (2) Open the UI at port 3001 and create an admin account.. Validate on the free tier first, then wire into production.

What is the #1 pitfall with Uptime Kuma (Self-Host Monitoring)?

The most frequent issue is: Monitor shows down but site is up — the monitor's expected status code or keyword filter is too strict; check the monitor's 'Keyword' and 'Accepted Status Codes' settings.. Run a pre-launch checklist item by item, and add policy/config scanning in CI.

What are the best practices for Uptime Kuma (Self-Host Monitoring)?

Best practices for Uptime Kuma (Self-Host Monitoring) include: Run Uptime Kuma on a different host than the services it monitors, so a single-host failure does not blind your monitoring.; Use push monitors for cron jobs and backups — the job pings Kuma on success, and Kuma alerts if the ping stops (job hung or failed).; Add a certificate-expiry monitor for every TLS endpoint so you are alerted 14 days before expiry, not on the day it breaks.. The first one — "Run Uptime Kuma on a different host than the services it monitors, so a single-host failure does not blind your monitoring." — should be a team default baked into your IaC templates.

How do I control cost and avoid bill surprises with Uptime Kuma (Self-Host Monitoring)?

Three ways to prevent overspend: (1) tag every resource with env/team and enable billing alarms; (2) set budget thresholds to trigger Slack/email alerts; (3) review idle resources in Cost Explorer regularly and clean them up. Most Uptime Kuma (Self-Host Monitoring) options offer a free tier — validate within free quota before scaling.