The short answer
Pick Uptime Kuma if what you need to know is whether your sites and services answer: it is the quickest to set up, alerted within half a minute in our test, and needs nothing on the servers it watches. Pick Zabbix if you also want to know why a server is struggling, with CPU, memory and disk figures and ready-made limits for them, all set up by clicking in one program. Pick Prometheus and Grafana if you want the best dashboards and would rather keep your setup in text files, and can live with slower alerts and more memory.
The three overlap only in part. Uptime Kuma checks from the outside and knows nothing about a server's CPU or disk. Zabbix and Prometheus collect figures from inside each server, and need extra setup to check a website. That is why it often makes sense to run Uptime Kuma next to one of the other two.
What we tested
We installed all three on one Melonslab VC-P Alloy (2 vCPU, 8 GB) with Debian 13, each by following our own guide, and ran them side by side:
- Uptime Kuma 2.5.6, in one container under the user
kuma. - Zabbix 7.0.31 with PostgreSQL 16, in a pod, and the Zabbix agent 2 on the server.
- Prometheus and Grafana: Prometheus 3.15.0, Alertmanager 0.34.1 and Grafana 13.2.4 in a pod, and node_exporter 1.9.0 on the server.
All three watched the same two HTTPS sites on the server, behind Caddy, and Zabbix and Prometheus also watched the server's own CPU, memory and disk. Then we stopped one of the sites four times, and timed how long each took to send an alert, and how long to send the all-clear once the site was back. Uptime Kuma sent its alerts to ntfy, and Zabbix and Alertmanager to a test webhook receiver on the server; the times are when each message arrived. Afterwards we ran each guide's backup, rebooted the server, and saw all three come back by themselves.
The numbers
| Uptime Kuma | Zabbix | Prometheus and Grafana | |
|---|---|---|---|
| Memory at idle | 120 to 135 MB | 130 to 140 MB in the pod, and 50 MB for the agent | 345 to 405 MB in the pod (Grafana 290 to 350 MB), and 26 MB for node_exporter |
| Disk: images | 1.76 GB | 520 MB | 1.78 GB |
| Disk: data after two hours | under 2 MB | 250 MB (the database) | 4 MB |
| Containers | 1 | 3, and an agent on each server | 3, and node_exporter on each server |
| Time for the guide's commands to finish | about 1.5 minutes | about 3 minutes | about 1.5 minutes |
| Alert after a site stopped | 18 to 26 seconds | 15 to 22 seconds | 1 minute 56 seconds to 2 minutes 4 seconds |
| All-clear after it was back | 17 to 20 seconds | 14 to 17 seconds | 4 minutes 42 seconds to 4 minutes 58 seconds |
| Watches CPU, memory and disk | no | yes | yes |
The installation times are how long the commands took to run, image downloads included, not the time you need to read the guide and type them. The website checks in Zabbix and Prometheus are not in our guides for them: the section on features below shows what we added.
With all three running, plus Caddy, ntfy and the two test sites, the server used 1.6 GB of its 8 GB.
Setup
Uptime Kuma is one container and one Caddy block. On first start its web page asks for a database, where SQLite is fine, and an account, and then you add monitors in a form. Nothing needs to be installed on the servers you watch.
Zabbix is three containers, a server, a web interface and PostgreSQL, and the server creates its database by itself on first start, which took under a minute. You then change the default Admin password, install the agent on each server you watch, and point Zabbix at it. Its guide has the most steps of the three, but every one after the start is clicking in the web interface.
Prometheus and Grafana is three containers, four configuration files in YAML, and node_exporter on each server. Grafana's settings in its guide also turn off its calls home to grafana.com. Once it runs, a ready-made dashboard is one import away.
One thing caught us out with all three running on the same server as the sites they watch. A rootless container that shares the server's address cannot reach the sites behind Caddy on that same server. The Uptime Kuma guide has a step for that. The Zabbix and Prometheus pods got Connection refused, and the same change broke their way of reaching the agent and node_exporter, so we ran their website checks from the server itself instead. Checks of sites on other servers worked from the pods. It is better to watch a server from somewhere else anyway: a monitor on the server that goes down cannot tell you about it.
Uptime checks, host figures and dashboards
Uptime Kuma checks from the outside: HTTP(s), ping, TCP ports, DNS, certificates and more, every 60 seconds by default, and it can publish a status page. It has no agent, and cannot tell you that a disk is filling up or that memory is running out, only that something stopped answering.
Zabbix collects figures from inside each server through its agent. Its Linux by Zabbix agent template brought CPU, memory, disk, network and process figures, graphs, and almost 80 ready-made triggers, the moment the server's agent answered. It even opened a problem that /etc/passwd had changed when we added a user. To watch a website, you add a web scenario to a host and then write a trigger for it by hand. A web scenario for a site elsewhere worked from the pod. For our two sites on the same server, we used an item that the agent checks, web.page.regexp, which reads the HTTP status code, and a trigger that fires when it is not 200.
Prometheus collects the same kind of figures through node_exporter, and Grafana draws them: the Node Exporter Full dashboard gave the clearest view of CPU, memory, disk and network of the three. Alerts are rules you write in PromQL, and the guide's two rules cover a server that stops answering and a disk over 85 % full. To check a website, Prometheus needs one more program, blackbox_exporter, which is not in our guide. We installed it from Debian's package prometheus-blackbox-exporter, added a scrape job for the two sites, and a rule that fires when probe_success has been 0 for a minute.
Alerts
Uptime Kuma has dozens of notification services built in, ntfy among them, and you pick one in a form. With its defaults, it alerts on the first failed check, so it reported the stopped site within 18 to 26 seconds, and sent Up within 20 seconds of it being back. With checks every 60 seconds, it can take up to a minute.
Zabbix opened the problem within 15 to 22 seconds, as its item ran every minute too, and closed it within 17 seconds of the site being back. It sends alerts through media types: email, and webhooks for about 30 services, such as Slack, Telegram, Discord and Mattermost, but none for ntfy in 7.0. For our test we added a webhook of our own, a few lines of JavaScript. The action that sends problems to the administrators is switched off at first, and the new media type was too: our first alert was never sent until we switched it on.
Alertmanager was the slowest by design, and it was the same every time: about two minutes to the alert, and about five minutes to the all-clear. The rule waits a minute, Prometheus checks its rules once a minute, and Alertmanager waits 30 seconds for other alerts to send with it. It sends updates to an open alert at most every five minutes, which delays the all-clear. All of these are settings you can lower. In return, a short glitch never wakes you up.
Resources
Uptime Kuma used 120 to 135 MB, and Zabbix 180 to 195 MB counting its agent. Prometheus and Grafana used about twice as much as Zabbix, 370 to 430 MB with node_exporter, almost all of it Grafana, between 290 and 350 MB. Prometheus itself used about 40 MB, and Alertmanager 15 MB. blackbox_exporter, for the website checks, added another 30 MB.
On disk, it is the other way round. Uptime Kuma's rootless image is 1.76 GB, as big as Prometheus and Grafana together, and Zabbix's three images are 520 MB. Zabbix's database starts at 250 MB, before it has collected anything, and grows with the figures it keeps. Prometheus' data took 1.5 MB after two hours for one server and two sites; its guide limits it to 30 days and 5 GB. All three fit easily on the Alloy plan, which has SSD storage: Zabbix's database and Prometheus write all the time.
Updates and backups
All three follow image tags that Podman updates daily. Uptime Kuma's 2-rootless and Zabbix's alpine-7.0-latest stay within one major release. Zabbix 7.0 is a long-term support release, with full support until June 2027 and security fixes until June 2029. The Prometheus and Grafana guide uses latest, which also moves to new major versions, so read their upgrade notes or pin a tag. The agents come from Zabbix's own repository and need apt upgrade; node_exporter comes from Debian and gets its security updates.
Backups are easiest with Uptime Kuma: one volume, everything included, with Kuma stopped for a moment. Ours was 336 KB. Zabbix's pg_dump runs while Zabbix keeps working, and holds hosts, settings and all the figures, 4.6 MB after 45 minutes. Grafana's backup is a volume and a file with the configuration, 2.3 MB, and leaves out Prometheus' figures, which rebuild themselves.
Licence and cost
We checked the projects' own pages on 14 October 2026.
- Uptime Kuma is open source under the MIT licence. There is no paid edition or hosted service, and the project is funded by donations.
- Zabbix is open source under the GNU AGPL 3.0 since version 7.0, and under the GPL 2.0 before that. Zabbix says it has no licence fees, no device limits and no locked features. Zabbix LLC sells support subscriptions, from €245 a month billed yearly, and a hosted Zabbix Cloud from €50 a month.
- Prometheus, Alertmanager, node_exporter and blackbox_exporter are open source under the Apache 2.0 licence. Grafana is open source under the GNU AGPL 3.0. Grafana Labs also sells Grafana Enterprise and a hosted Grafana Cloud, with a free tier of 10,000 metric series kept for 14 days, and a Pro tier from $19 a month plus usage.
Run on your own server, all three cost nothing beyond the server.
Which one to pick
- Only sites and services to watch? Uptime Kuma. It is the simplest to set up and to keep, and the fastest to alert. It cannot see inside a server.
- Servers to watch, and one program that does it all by clicking? Zabbix. It gives you figures, graphs and sensible limits as soon as an agent answers, and alerts within a minute. Its interface is dense, website checks take a trigger you write yourself, and it has no built-in ntfy alerts.
- Servers to watch, and you like dashboards and text files? Prometheus and Grafana. It has the best graphs, and the whole setup fits in a few files you can keep in Git. It used the most memory, website checks need blackbox_exporter, and with its default timings, alerts take about two minutes and the all-clear about five.
Each guide runs comfortably on the Alloy plan, and all three together used 1.6 GB of its 8 GB. Uptime Kuma works best on a different server from the one it watches, so that it can tell you when that server goes down. A good pair is Uptime Kuma on one server and Zabbix or Prometheus on another, each watching the other.