Beszel vs Uptime Kuma
Beszel watches the server: CPU, memory, disk, Docker stats, even S.M.A.R.T. drive health. Uptime Kuma watches the service: HTTP, TCP, DNS, ping, and a public status page. Two different jobs. Most self-hosters end up running both, which is $6/mo on InstaPods.
Should I use Beszel or Uptime Kuma?
Use both. Beszel watches the server from the inside - CPU, memory, disk, Docker stats - and Uptime Kuma watches your services from the outside over HTTP, TCP, DNS and ping. Neither replaces the other. Running only one? Public sites or APIs, start with Uptime Kuma. A VPS or homelab fleet, start with Beszel. If Uptime Kuma is the half you are choosing, the two questions people actually get stuck on are whether to keep paying a hosted prober, which is UptimeRobot vs Uptime Kuma, and whether to define checks in YAML instead of clicking them in, which is Gatus vs Uptime Kuma. Every Uptime Kuma comparison sits in one place.
Last updated: 2026-08-25Quick Comparison
| Feature | Uptime Kuma | Beszel |
|---|---|---|
| The question it answers | Is it responding? | How is the machine holding up? |
| What it measures | HTTP(s), keyword, JSON query, TCP, ping, DNS, WebSocket, push, Docker, Steam | CPU, memory (incl. swap and ZFS ARC), disk usage, disk I/O, network, load average, temperature, fan speed, GPU, battery |
| Where it watches from | Outside, one vantage point per install | Inside, one agent per server, reporting to a hub |
| Public status page | Yes, built in and customizable | No |
| Disk health (S.M.A.R.T.) | No | Yes, plus drive-failure notifications |
| Docker visibility | Up or down, as a monitor type | CPU, memory and network history per Docker workload |
| Notification targets | 106 notification integrations in the 2.5.3 source tree | 23 documented targets, generic webhook included |
| Runtime | Node.js server with SQLite | Go binaries: PocketBase hub, tiny standalone agent |
| Latest release (25 Aug 2026) | 2.5.3, shipped 22 Aug 2026 | v0.18.8, shipped 17 Aug 2026 |
| GitHub stars | 90,579 | 24,627 |
| License | MIT | MIT |
| Price on InstaPods | $3/mo Launch pod (1 vCPU, 512MB RAM, 10GB disk) | $3/mo Launch pod (1 vCPU, 512MB RAM, 10GB disk) |
What Uptime Kuma will never tell you
Trade-offs to weigh before committing.
It never looks at the server
Uptime Kuma's ten monitor types - HTTP(s), keyword, JSON query, TCP, ping, DNS record, WebSocket, push, Steam and Docker, per the project README - all answer the same question: did something reply? None of them read CPU, memory, disk or load average. Your box can sit at 98% memory for a week and every monitor stays green until something finally falls over.
No disk health, no capacity warning
There is no S.M.A.R.T. check and no disk-usage trend, so a dying drive or a partition creeping toward full is invisible right up to the outage. Beszel's docs list S.M.A.R.T. data with drive-failure notifications as a headline feature, which is the exact gap.
Down, but never why
A red monitor tells you a URL stopped answering. It cannot tell you whether that was memory exhaustion, a full disk, CPU saturation or a network problem - which is the very next question you will be asking at 2am with no data to answer it.
One vantage point when self-hosted
Self-hosted Uptime Kuma checks from wherever you put it. Park it on the same server or the same network as the thing it watches and a single outage takes out both the service and the monitoring that was supposed to page you.
What Beszel adds on top
What you get when you pick this stack.
Metrics Uptime Kuma has no concept of
The Beszel agent reports CPU, memory including swap and ZFS ARC, disk usage and disk I/O, network, load average, temperature, fan speed, GPU usage across Nvidia, AMD and Intel, and battery charge. That list is straight from the supported-metrics table on beszel.dev. None of it exists in Uptime Kuma.
Docker stats with history
CPU, memory and network usage tracked over time for each Docker workload, so you can see which one started eating the box, without SSHing in to run docker stats and guess from a live snapshot.
One hub, every server you own
Beszel splits into a hub and an agent. The hub is your $3/mo Launch pod on InstaPods - 1 vCPU, 512MB RAM, 10GB disk. The agent is a small Go binary you drop on each machine you want to watch, at no extra hosting cost. Five servers or fifty, the bill stays $3/mo.
Alerts on the numbers, not the corpse
Configurable thresholds on CPU, memory, disk, bandwidth, temperature, fan speed, load average and status, delivered to any of the 23 notification targets documented on beszel.dev - ntfy, Gotify, Slack, Signal, Telegram, Matrix and a generic webhook among them. You get paged while there is still time to act.
Real Cost Comparison
Watching 5 servers and 20 public endpoints.
- Uptime Kuma on a $3/mo Launch pod
- All 20 endpoints, unlimited monitors
- Public status page included
- Zero server metrics: no CPU, memory, disk or S.M.A.R.T.
- Beszel hub on a $3/mo Launch pod
- Agents on all 5 servers: free
- CPU, memory, disk, I/O, network, S.M.A.R.T., Docker stats
- No HTTP checks and no status page - add Uptime Kuma for $6/mo total
Frequently Asked Questions
Should I use Beszel or Uptime Kuma?
Use both. Beszel watches the server from the inside - CPU, memory, disk, Docker stats - and Uptime Kuma watches your services from the outside over HTTP, TCP, DNS and ping. Neither replaces the other. Running only one? Public sites or APIs, start with Uptime Kuma. A VPS or homelab fleet, start with Beszel.
Do I need both Beszel and Uptime Kuma?
If you run public services on servers you own, yes. Uptime Kuma catches the outage; Beszel tells you what caused it and warns you before the next one. On InstaPods they are two $3/mo Launch pods, so the full picture costs $6/mo. Both are MIT licensed, so there is no per-monitor or per-node pricing on either side.
Can Uptime Kuma monitor server CPU and memory?
No. Every one of Uptime Kuma's ten monitor types checks whether an endpoint replies - HTTP(s), keyword, JSON query, TCP, ping, DNS record, WebSocket, push, Steam and Docker. None of them read host resource usage. For CPU, memory, disk and load you need a resource monitor like Beszel, Netdata or Prometheus with node_exporter.
Which one should I install first?
Pick by what you own. If your pain is customers noticing an outage before you do, install Uptime Kuma first: it takes about five minutes and gives you a status page. If your pain is servers quietly running out of memory or disk, install Beszel first, because it is the only one of the two that can see that coming.
What does Beszel monitor that Uptime Kuma does not?
CPU, memory including swap and ZFS ARC, disk usage, disk I/O, network throughput, load average, temperature, fan speed, GPU usage on Nvidia, AMD and Intel, battery charge, S.M.A.R.T. drive health, and per-workload Docker stats. That is the full supported-metrics list from beszel.dev, and Uptime Kuma covers none of it.
Is there one tool that does both?
Netdata comes closest, pairing deep resource metrics with some availability checking, but its agent uses 200-500MB RAM per node against Beszel's single Go binary. Running two focused tools stays lighter and each does its own job properly. See our Beszel vs Netdata comparison for the full breakdown.
How much does it cost to run both on InstaPods?
$6/mo. Each app runs on its own Launch pod at $3/mo, which is 1 vCPU, 512MB RAM and 10GB disk, with an HTTPS URL and nightly backups included. Beszel agents on the servers you monitor are free, so adding more machines to the hub does not change the bill.
Are Beszel and Uptime Kuma still actively maintained?
Both, actively. Uptime Kuma shipped 2.5.3 on 22 August 2026 and has 90,579 GitHub stars; Beszel shipped v0.18.8 on 17 August 2026 with 24,627 stars. Both are MIT licensed, checked 25 August 2026. InstaPods rebuilds its 1-click images against upstream releases, so a new pod starts on a current build.
Deploy Beszel in one click
Beszel hub on a $3/mo pod, agents free on every server you own. Add Uptime Kuma next to it for $6/mo total and you have both halves of the picture.
Deploy Beszel