Physical Address
304 North Cardinal St.
Dorchester Center, MA 02124
Ask “Uptime Kuma or Beszel?” in a homelab forum and you’ll get answers that talk past each other, because the question itself is malformed. It’s like asking whether you need a smoke detector or a thermometer. Both tell you something is wrong with your house. Neither tells you the same thing.
Uptime Kuma watches your services from the outside: is the HTTP endpoint responding, is the DNS record resolving, is the TCP port open. Beszel watches your servers from the inside: how much CPU is pegged, how full is the disk, is a container quietly eating memory before it crashes. A service can return a healthy 200 status code while the host underneath it is three minutes from an out-of-memory kill. A server can sit at a comfortable 12% CPU while the application on it has deadlocked and stopped responding entirely. Each tool is blind to the failure mode the other one catches.
This isn’t a comparison in the sense of picking a winner. It’s a map of where each tool’s coverage ends, so you know exactly what you’re missing if you’re only running one.
Beszel: What’s Actually Happening on the Machine
Beszel is a self-hosted server monitoring platform written in Go, built around a hub-and-agent model. The hub is a single container a PocketBase-backed web UI that aggregates metrics from every server you point an agent at. The agent itself is deliberately minimal: it reports CPU, memory, disk I/O, network throughput, temperature, and (where available) GPU and SMART disk health back to the hub, plus per-container Docker stats if the host is running containers.
The number that gets cited most often is the agent’s footprint around 10-15MB of RAM at idle, which is a fraction of what a Netdata agent or a Prometheus node-exporter setup typically costs. That’s not a marketing detail, it’s the actual design philosophy: Beszel exists because Prometheus + Grafana + exporters + alerting rules is a lot of infrastructure to stand up just to see if a box is running hot.
What you see in the dashboard: a per-server view with historical graphs for CPU, memory, disk, and network, a container breakdown if you’re running Docker, and configurable alerts on thresholds — CPU sustained above X%, memory above Y%, disk approaching capacity, temperature climbing. Multi-user access with OAuth/OIDC support means you can hand a read-only view to a teammate without sharing admin credentials. Setup is a docker-compose file for the hub and a one-line agent install per host, with no query language and no dashboard-building required you get sensible defaults out of the box.
What it leaves unfilled: Beszel has no concept of your application layer. It doesn’t know that your Nginx container is running fine at the OS level while returning 502s to every visitor, because from the host’s perspective, the container is up, CPU and memory look normal, nothing is wrong. It also doesn’t check anything outside the servers it’s installed on no DNS resolution checks, no SSL expiry warnings, no “is this URL reachable from the public internet” verification. If your entire host is unreachable because of a network or DNS issue upstream, Beszel’s agent can’t report that, because the agent itself is offline along with everything else.
Uptime Kuma: What Your Services Look Like From Outside
Uptime Kuma takes the opposite vantage point. It doesn’t care what’s happening inside your server it cares whether the things your server is supposed to expose are actually reachable and behaving. HTTP(S) endpoints, TCP ports, DNS records, ping targets, keyword matches inside a page’s response, SSL certificate expiry, and via its Docker Container monitor type whether a specific container is in a running state (though this is a shallow check, not a metrics feed).
What you see in the dashboard: a live, WebSocket-updated grid of monitors, each with a green/yellow/red heartbeat bar going back through recent history, response time graphs, and an uptime percentage. Add a monitor, pick a type, set an interval, attach a notification channel, done. It’s built for breadth of protocol coverage and speed of setup rather than depth of any single metric.
What it leaves unfilled: Uptime Kuma has no idea why a service is down. It knows your API stopped responding at 3:14 AM; it has no visibility into whether that’s because the process crashed, the disk filled up, memory got exhausted, or the host itself is on fire. It also doesn’t monitor resource trends at all there’s no CPU or memory graph anywhere in Uptime Kuma, because that’s simply not what it’s built to see. A host that’s been climbing toward 95% memory usage for six hours, about to OOM-kill your database, will look completely fine in Uptime Kuma right up until the moment it isn’t.
Side-by-Side
| Beszel | Uptime Kuma | |
|---|---|---|
| Vantage point | Internal inside the host | External outside looking in |
| What it tracks | CPU, memory, disk I/O, network throughput, temperature, GPU, SMART health, per-container Docker stats | HTTP/HTTPS status, TCP port state, DNS resolution, ping, keyword matching, SSL/cert expiry |
| Answers the question | “Is this server healthy?” | “Is this service reachable?” |
| Architecture | Hub (PocketBase-based web UI) + lightweight Go agent per host | Single container, SQLite-backed, no agents polls targets directly |
| Resource footprint | Very low agent runs on ~10-15MB RAM | Low single container, scales with monitor count and check interval |
| Setup complexity | Docker Compose for the hub, one-line agent install per host | Single docker run or Compose file, add monitors through the UI |
| Historical data | Yes trend graphs for every tracked metric | Yes, but limited to uptime/response-time history, not resource metrics |
| Alerting | Threshold-based (CPU/memory/disk/temp/bandwidth) | State-change based (up/down transitions), plus certificate expiry warnings |
| Blind spot | Application-layer failures (process hung, wrong response, deadlock) while the host itself looks fine | Root cause of a failure no resource, process, or hardware visibility at all |
| Best single-tool fit | You manage the hardware/hosts and want early warning before resources become a problem | You need to know the moment a public-facing service stops responding |
Where One Starts and the Other Picks Up
In a real self-hosted setup, these two tools don’t overlap so much as hand off to each other, and the handoff points are worth being explicit about.
The classic sequence: memory usage climbs slowly on a host running several services (Beszel would show this trending up over hours), the host eventually can’t allocate memory for a new connection, the application hangs or gets OOM-killed, and now Uptime Kuma’s HTTP check starts failing and fires a notification. Without Beszel, you find out about the problem only when Uptime Kuma alerts after the outage has already started. With Beszel in place, the memory trend was visible hours earlier, and a threshold alert at 85% usage would have given you a chance to intervene before the outage happened at all. This is the core argument for running both: Beszel gives you the leading indicator, Uptime Kuma gives you the confirmation that something user-facing actually broke.
The inverse case matters too. A reverse proxy misconfiguration — a bad Nginx rule, an expired upstream certificate, a DNS record pointed at the wrong IP can take a service offline while the underlying host’s CPU, memory, and disk all look completely normal. Beszel would show you a perfectly healthy server the entire time. Only Uptime Kuma, checking from the outside, would catch that anything is wrong at all. If you’re running a reverse proxy in front of your self-hosted services, this is exactly the failure mode that justifies keeping both an internal and an external check on the same stack — the proxy config is a layer neither tool fully owns on its own, but Uptime Kuma is the one that will actually notice when it breaks.
In a homelab context, the practical layout usually looks like this: Beszel’s hub runs as one more container on your primary host (or a small dedicated VM), with lightweight agents deployed to every physical or virtual machine you want visibility into this maps cleanly onto a Proxmox environment, where each VM or LXC container gets its own tiny agent reporting back to a single hub, giving you a fleet-wide resource view without touching Prometheus. Uptime Kuma runs alongside it, checking the actual services your reverse-proxied web apps, your Git server, your DNS, whatever’s externally or internally reachable and both tools feed notifications into the same channels (Discord, Telegram, Gotify see our notification setup guide if you haven’t wired that up yet) so you’re not checking two separate dashboards to get the full picture.
Neither tool needs to know the other exists. There’s no integration between them, no shared database, no dependency you’re just running two small, focused programs that each do one job well, and pointing their alerts at the same inbox.
Decision Framework
Start with Uptime Kuma if: your immediate concern is “will I know when my site/API/service goes down.” This is almost always the first tool people reach for, because service downtime is the failure mode that actually affects users and gets noticed. If you’re running anything public-facing, this is non-negotiable table stakes regardless of what else you add later.
Start with Beszel if: you’re managing more than a couple of physical or virtual hosts and have been finding out about resource exhaustion after the fact a host that ran out of disk overnight, a container that slowly leaked memory over a week. If your problem is “I don’t actually know how loaded my servers are,” Beszel answers that directly and with almost no setup cost.
Add the second tool once the first one’s gaps start costing you. The most common trigger is exactly the memory-leak-then-outage sequence above: Uptime Kuma tells you something broke, but you’re left guessing why until you add resource-level visibility. The reverse trigger Beszel shows healthy hosts while a service is actually unreachable to users is less common but just as real, usually surfacing after a proxy or DNS misconfiguration nobody caught because nothing was checking from outside.
Running both is not overkill. Combined, the two containers run on a fraction of the resources a single Grafana + Prometheus stack would use, and neither requires you to learn a query language or build a dashboard from scratch. For a homelab or small self-hosted infrastructure, “internal health plus external availability, each from a purpose-built lightweight tool” is a more practical target than trying to get one tool to do both jobs adequately. Uptime Kuma will never show you a memory graph, and Beszel will never tell you your DNS is broken accept that division of labor rather than fighting it, and you end up with better coverage than either tool provides alone.
