Uptime Kuma
Monitoring & StatusEasy self-hosted uptime monitoring tool
Replaces Pingdom, UptimeRobot
Service up/down checks and alerts
Homelab Monitoring Stack
Know when things break before your users do.
Uptime Kuma pings every service and alerts the moment one goes down, Beszel tracks per-host and per-container resource usage with almost no setup, and Prometheus plus Grafana provide the heavyweight metrics pipeline once you outgrow simple checks. Healthchecks watches the things that fail silently — cron jobs and backups that simply stop running. Start with Uptime Kuma and Beszel; add the Prometheus layer when you need query-able history.
The apps and their roles
Beszel
Monitoring & StatusLightweight server monitoring with a clean hub
Replaces UptimeRobot
Lightweight host and container metrics
Prometheus
Monitoring & StatusMetrics-based monitoring and alerting toolkit
Replaces Datadog
Metrics collection and querying
Grafana
Monitoring & StatusOpen observability dashboards and visualization
Replaces Datadog
Dashboards over Prometheus data
Healthchecks
Monitoring & StatusCron job and scheduled task monitoring
Replaces Pingdom
Dead-man switch for cron and backups
Last reviewed Oct 11, 2026 · 649 words
Monitoring that runs on the server it monitors goes quiet at exactly the moment you need it. That is the one wiring decision this stack turns on: put Uptime Kuma and Healthchecks somewhere other than the box they watch, even a second small machine, and the rest can live wherever is convenient. All five apps together come to about 1,664 MB of RAM by the directory's estimates, and the first two you should deploy, Uptime Kuma and Beszel, account for only 384 MB of that.
What each one watches
The five apps answer different questions, and they barely overlap.
| App | Answers | Rated | Directory RAM estimate |
|---|---|---|---|
| Uptime Kuma | Is the service reachable right now? | Easy | 256 MB |
| Beszel | How hard is each host and container working? | Easy | 128 MB |
| Healthchecks | Did the cron job or backup actually run? | Easy | 256 MB |
| Prometheus | What did any metric do over the past weeks? | Medium | 512 MB |
| Grafana | What does that history look like? | Medium | 512 MB |
Uptime Kuma probes from the outside over HTTP, TCP, DNS and more, then alerts through its long list of notification integrations. Beszel runs a hub plus a small agent on each host, reporting CPU, memory, disk and per-container stats. Healthchecks inverts the model: your backup script pings a unique URL when it finishes, and Healthchecks alerts when a ping does not arrive on schedule. Prometheus pulls metrics from exporters on a schedule and stores them; Grafana reads Prometheus as a data source and draws the dashboards.
Why use Healthchecks if Uptime Kuma already alerts?
Because the failures that hurt most produce no error to catch. A backup cron entry that was deleted, a container that stopped running its schedule, a script that exits before reaching the upload step: none of these make any service go down, so Uptime Kuma stays green. Healthchecks is a dead-man switch that alerts on silence. Add one curl to the end of every backup job and you learn about a broken backup the next morning rather than on the day you need to restore.
Deploy in this order
Start with Uptime Kuma and point it at every service you run. Its whole UI is a live websocket connection, so enable websocket pass-through on your proxy. All its state lives in /app/data, which is the one folder to back up. Then Beszel for resource history with almost no setup. Add Healthchecks the same week you set up backups.
Prometheus and Grafana come last, when you have a question the first three cannot answer. Prometheus keeps 15 days of metrics by default, so raise --storage.tsdb.retention.time if you want longer history, and it has no built-in authentication, so keep it internal. Grafana's default login is admin/admin unless you set GF_SECURITY_ADMIN_PASSWORD before first start, and its container runs as UID 472, so chown the data volume to match. Note that Grafana and several other apps default to port 3000; remap before they collide.
The mistake: alerts that go nowhere
The commonest failure is not technical. People deploy the dashboards, never configure a notification channel, and discover outages by looking. Set up one notification target in Uptime Kuma and Healthchecks before adding a second monitor, and send a test alert to your phone. The second mistake is the one in the opening paragraph: if the monitoring host is also the monitored host, a kernel panic takes both down and nobody is told.
What I'd do
Uptime Kuma and Beszel on day one, ideally on a separate small machine, Healthchecks wired into every backup job, and the Prometheus and Grafana pair only once you have a real question about history. The homelab monitoring guide covers alert tuning, and the Beszel vs Uptime Kuma comparison explains why you want both rather than one.