comparing self-hosted
Uptime Kuma vs Zabbix: from outside, or from inside?
Both are free, both are self-hosted, and that is where it ends. Zabbix collects metrics from inside your servers through agents. Uptime Kuma asks your services from the outside whether they still answer. Choosing wrongly leaves you either running a monitoring platform nobody has time for, or holding a checker that cannot tell you why anything broke.
The facts, side by side
| Uptime Kuma | Zabbix | Uptimepage | |
|---|---|---|---|
| license | MIT | AGPL-3.0 since 7.0 | AGPL-3.0 |
| what it watches | services, from outside | hosts, from inside | services, from outside |
| agents required | none | one per host for the useful parts | none, optional private probe |
| what you run | one container | server + database + PHP frontend | one binary + compose |
| endpoint checks | 31 types incl. DBs · MQTT · browser | web scenarios + simple checks | HTTP · TCP · DNS · TLS · ping · domain |
| infrastructure metrics | none | CPU · memory · disk · logs · DBs | none |
| checks from elsewhere | via Globalping add-on | proxies you host | multi-region, run your own |
| customer status page | yes, RSS only | none, dashboards instead | branded, email + webhook subs |
| incidents | posted by hand | triggers + events, internal | auto-opened from checks |
| config as code | UI only, no management API | JSON-RPC API, community Terraform | Terraform · REST · MCP, official |
| teams & roles | single login | users · groups · roles | orgs + roles |
Zabbix requires MySQL 8.0.30+, MariaDB 10.5+, or PostgreSQL 13-18 (optionally with TimescaleDB), plus PHP 8.0-8.5 on Apache 2.4 or Nginx 1.20.
Zabbix web scenarios assert on status codes, required strings and response time. The server must be built with cURL support, and redirects are capped at ten.
No official Zabbix Terraform provider exists. The registry carries at least five community providers, maintained independently of the project.
Verified July 2026 against Zabbix documentation, its license page and its lifecycle policy, and against the Uptime Kuma repository. Zabbix 7.4 reaches end of life on 30 September 2026, so recheck this table around the 8.0 release.
The split that decides it
Zabbix is agent-based. You install an agent on each host, and it reports CPU, memory, disk, processes, log lines and database internals back to a central server that stores everything and evaluates triggers. Uptime Kuma is agentless. It sits somewhere and makes requests, and if the request comes back correct within the timeout, the service is up. That is the whole difference, and everything below follows from it. Zabbix answers why a server is unhealthy. Uptime Kuma answers whether a customer can reach it. Those are different questions and neither tool answers the other one well.
What Zabbix actually takes to run
More than people expect. A working install is a Zabbix server, a database, and a PHP frontend behind a web server. Zabbix supports MySQL 8.0.30 and up, MariaDB 10.5 and up, or PostgreSQL 13 to 18, optionally with the TimescaleDB extension. The frontend wants PHP 8.0 to 8.5 with about a dozen extensions, on Apache 2.4 or Nginx 1.20. Monitoring anything across a network boundary usually adds a Zabbix proxy. None of this is hard for someone who runs infrastructure for a living, and all of it is real work you keep doing: upgrades, database growth, and a schema that is the biggest single thing to maintain. Zabbix's own lifecycle page lists 7.4 as the current standard release and 7.0 as the supported LTS. Everything up to 6.4 was GPL-2.0; from 7.0 onward Zabbix is AGPL-3.0.
Zabbix can check a website, but it is a side job
It genuinely can. Zabbix web scenarios run a sequence of HTTP steps and assert on status codes, on required strings in the response body, and on response time, which covers a login flow or a click path. There are also simple checks like icmpping and net.tcp.service that need no agent at all. What you should know before betting on it: the server has to be built with cURL support, redirects are capped at ten, and secret macros cannot be used in URLs because they resolve masked. It works. It is also configured like everything else in Zabbix, which means hosts, templates, items and triggers rather than pasting in a URL.
What Uptime Kuma gives up
Depth, and anything resembling a team. Kuma has 31 monitor types and 94 notification integrations and installs as one container in five minutes, and someone who is not an engineer can add a check. But it has one shared login, so everyone who can see the dashboard can change anything, and there are no roles. It has no official API for managing monitors. And it knows nothing about the inside of your machines: a host at 95 percent disk is invisible to Kuma right up until the service falls over. Zabbix would have warned you a week earlier.
Neither one keeps your config in Git
This is the part that bites teams later. Uptime Kuma is UI-only with no management API, so the monitors exist wherever someone clicked them. Zabbix is better, with a full JSON-RPC API and templates you can export as YAML or XML, but there is no official Terraform provider. The registry carries at least five community ones, from nzolot, claranet, elastic-infra, fe80 and tpretz, maintained at whatever pace their authors choose. If your infrastructure is declared in Terraform and reviewed in pull requests, your monitoring being a pile of manual UI state is a real gap, and adopting an unofficial provider for it is a bet on a volunteer.
The blind spot they share
Both run inside the estate they watch. If the host running your Zabbix server dies, nothing collects and nothing alerts. If your single Kuma container sits on the machine that just went down, the same. Self-hosted monitoring that lives next to the thing it monitors will always miss the outage that takes both down, and that outage is the one your customers notice. It is the whole argument for a probe somewhere else.
Where Uptimepage fits
Uptimepage does the outside-in job, from several regions by default, and you can run your own probe agent inside the network for the private targets an external checker cannot see. It checks over HTTP, TCP, DNS, TLS, ping and domain expiry at 60 seconds on the free tier and 10 seconds self-hosted. The config lives in Git through a Terraform provider we publish and maintain, a REST API and an MCP server, so monitoring is reviewed like the rest of your infrastructure. On top: a branded status page with confirmed email and webhook subscribers, incidents opened automatically from failing checks, and organizations with roles instead of one shared password. It is one Rust binary. It is also AGPL-3.0, the same license Zabbix uses, so self-hosting is a real exit rather than a trial. It does not replace Zabbix for CPU graphs and capacity planning, and it is not trying to. Plenty of teams run Zabbix inside and Uptimepage outside.