Uptime Kuma vs UptimeEZ

The self-hosted favourite, and the honest comparison

Every fact below was read from their own pages on 2026-08-02. Where their page does not mention something, we write "not announced" rather than "cannot do it".

What Uptime Kuma is

Uptime Kuma is the self-hosted monitor everybody recommends, and deservedly: MIT licensed, ten monitor types from TCP ports to Docker containers, more than ninety notification services, more than fifty interface languages. It is built for someone who owns a server and is at ease with Docker or with Node.js 20.4 and up under PM2, and who wants the measurements to stay on that machine. If you monitor infrastructure rather than websites, it is the better of the two tools and we will not pretend otherwise. Where we differ is narrow and worth stating plainly: it needs a machine you control rather than the shared hosting most of our users already pay for, and its repository does not announce reading the rendered page or catching a database error printed inside a valid one.

Side by side

6 / 3

UptimeEZ takes 6 of the criteria below, Uptime Kuma takes 3, and 5 are a draw. We chose the criteria, so read the row that matters to you rather than the score.

What you might need Uptime Kuma UptimeEZ
Licence MIT MIT
What it needs to run Docker, or Node.js 20.4 and up with PM2 Advantage: UptimeEZ. PHP 8.2 and a database
Runs on shared hosting No Advantage: UptimeEZ. Yes, that is the design goal
Monitor types Advantage: Uptime Kuma. HTTP, TCP, keyword, JSON query, WebSocket, ping, DNS, push, Steam, Docker HTTP pages, APIs and heartbeats
Notification services Advantage: Uptime Kuma. More than ninety Seven: email, Discord, Slack, Telegram, Teams, SMS, webhook
Reads the rendered layout Not announced Advantage: UptimeEZ. Nine signals and a silhouette
Finds a database error inside a 200 Not announced Advantage: UptimeEZ. Forty-one signatures, no setup
Tells you what to fix The check result Advantage: UptimeEZ. One of twenty-six causes, with the remedy
Read-only link per client Status pages Advantage: UptimeEZ. One link per client, scoped to their sites
Source code you can read MIT, the whole app MIT, the whole engine
Unlimited monitors and sites Yes, it is your server Yes, the hosted plan does not count them
Where the measurements are stored Your server, wherever it is Your server, or our dedicated OVH server in France
Interface languages Advantage: Uptime Kuma. More than fifty, community translated Ten
Leaving with your history Your database, you keep it Exportable, and the instance is deleted on request

advantage UptimeEZ advantage Uptime Kuma no tint: too close to call

What we read on their own pages

What Uptime Kuma does well

  • MIT licensed, and the whole application is readable
  • Ten monitor types: HTTP, TCP, keyword, JSON query, WebSocket, ping, DNS, push, Steam, Docker
  • More than ninety notification services
  • More than fifty interface languages, community translated
  • Unlimited monitors: it is your server, nobody counts them

Limits, as their pages state them

  • Needs Docker, or Node.js 20.4 and up with PM2
  • Does not run on plain shared hosting
  • No hosted service announced in the repository: you run and update the server
  • Reading the rendered page: not announced
  • A database error printed inside a 200: not announced

Both lists are facts read on their own pages on 2026-08-02, never our opinion of the product.

Where UptimeEZ is better

Both projects are MIT and both install on a machine you own, so openness is not the argument on this page and pretending otherwise would waste your time. Two other things are. What it takes to run: PHP 8.2 and a database, no Composer, no npm, no Docker, which is the shared hosting an agency already pays for instead of a server it has to keep alive. And what gets read: nine layout signals over the rendered page, forty-one signatures for errors printed inside a valid response, and a read-only link per client scoped to that client's sites.

Countable in the engine source, which is public and MIT: src/bootstrap.php for the PHP 8.2 floor, checked at boot, src/Check/Css.php for the nine layout signals, src/Check/Database.php for the forty-one error signatures, src/Client.php for the read-only client link.

Where Uptime Kuma is better

More monitor types, and it is not close: TCP ports, ping, DNS records, Steam servers, Docker containers. More than ninety notification integrations against our four. A large community and years of use in production. If you monitor infrastructure rather than websites, it is the better tool, and we would tell you so.

Source: https://github.com/louislam/uptime-kuma, read on 2026-08-02. Ours is open to the same reading: github.com/coeurduweb/uptimeez. Found a mistake? Tell us and we will correct it: we would rather be right than flattering. support@uptimeez.com.

Questions we are asked about Uptime Kuma

What I watch is containers and ports on my own box, not client websites. Kuma or UptimeEZ?

Uptime Kuma, without hesitating. It speaks ping, Steam and Docker, which UptimeEZ does not, and its ICMP ping is a deliberate refusal here rather than a gap. A homelab is the case Kuma was built for, and its more than ninety notification services will reach you wherever you already read your alerts. We would rather you installed the right one than ours.

Kuma and the UptimeEZ engine are both MIT and both install for nothing. What is the 9.90 EUR for?

For not owning the machine. The hosted plan is the same engine on our dedicated server in France, one database per customer, updated by us, and above all not sitting on infrastructure you also have to keep alive. Kuma announces no hosted service in its repository, so with Kuma that machine is always yours. If keeping a small server alive is something you enjoy, install either one and pay neither.

Uptime Kuma installs on a server, and so does the UptimeEZ engine. What if that server is the one that breaks?

Nothing warns you, with either tool, and it is the one mistake both of them let you make. A monitor installed beside what it watches dies in the same power cut and sends no alert, because sending the alert was its job. Kuma on a separate box you control, and UptimeEZ hosted on ours, both solve it by being somewhere else. The monitor and the sites must not share a machine.

We already run Kuma for our servers. What would UptimeEZ be pointed at?

At the websites, and only those. Kuma keeps the ports, the containers and the machines you own; UptimeEZ reads the client pages, where the failure is usually a page that still answers 200 while the layout has collapsed or a database error is printed inside it. If you would rather run a single tool, run the one that matches what breaks most often.

Kuma has years of contributors behind it. What happens to my monitoring if UptimeEZ stops?

The engine keeps running: it is MIT, and it sits either on your server or in an export from ours. That answer is smaller than theirs. A project with a large community and years of production use has a resilience a young one cannot claim yet. If you want the tool least likely to be abandoned, it is Kuma, and the licence is what makes the risk on our side survivable.

Out of these five questions, Uptime Kuma is the answer to 1 of them rather than UptimeEZ. A comparison that wins every question is not one you should believe, and you have already used one of these tools.

Every comparison, side by side

Or see all seven in one table, with a guide to choosing · What separates these tools, and how to test one

See it read a page for yourself

The demo resets every hour, sends nothing and saves nothing. Or install the engine on your own server: it is the same code.

Open the live demo See the pricing

Or check one address right now, free and without an account

Cookies here just count visits, with Google Analytics, and only if you say yes. What we store