Uptime Kuma alternative? Kuma tells you a site is down. PulseNode tells you why.

Uptime Kuma is the best free uptime monitor in self-hosting; this page won't pretend otherwise. PulseNode watches the inside of the server instead. Which you need depends on the question you're asking.

PulseNode · updated July 2026

If you're searching for an Uptime Kuma alternative, first make sure you need one. For free downtime pings and a public status page, Uptime Kuma is excellent: MIT licensed, 88k+ GitHub stars, actively maintained. This page is for the two questions Kuma can't answer. What were CPU, RAM and disk doing behind the outage? And who tells you when the box running your monitor is the box that died?

PulseNode, for its part, is a paid hosted service, closed source, not self-hostable, and young, run by one founder. Kuma is free and open. If that settles it, keep Kuma and close the tab.

The short answer: different categories, not a head-to-head

Uptime Kuma checks your services from outside and notifies you through 90+ services when something stops responding. PulseNode lives inside the box: CPU, RAM, disk, network, Docker and ports, with threshold and agent-offline alerts. One asks whether the thing is up; the other tells you what it's doing. They run side by side without conflict.

What Uptime Kuma does well (keep using it for this)

Free, MIT licensed, and actively maintained

Kuma has 88k+ stars and describes itself as "a fancy self-hosted monitoring tool", which undersells it. Version 2.4.0 shipped in late May 2026 with new SMS providers, RSS incident feeds, and a fast patch for a security bug in notification templates. The 2.x line is current and moving.

More check types than most paid uptime products

HTTP(s), TCP, keyword matching, JSON queries, WebSocket, ping, DNS records, push heartbeats, Steam game servers and Docker containers, at intervals down to 20 seconds. Add certificate expiry display, 2FA and a multi-language UI.

Notifications and status pages

When a monitor fails, Kuma notifies you through more than 90 services. It also hosts multiple status pages, each mappable to its own domain. PulseNode has no status pages at all; if you need one, keep Kuma.

What Uptime Kuma can't tell you: why the server is struggling

Host metrics are out of scope for Uptime Kuma by maintainer decision. Feature request #2603, asking for disk space and CPU usage, was closed as "not planned". The community workaround is a shell script that pushes CPU, RAM and disk numbers into Kuma's heartbeat monitors. It works the way duct tape works.

A server can return HTTP 200 while its disk sits at 97%, so Kuma stays green until writes start failing, and the first notification you get is the outage itself. External checks report downtime after it starts; host metrics warn you before. We wrote up the disk case in how to get an alert before a Linux disk fills up.

PulseNode's agent reports per-core CPU and load, RAM and swap, disk per mount with read/write throughput, network, and uptime, charted over 1h, 6h, 24h and 7d windows (Pro adds 14d and 30d). Alert rules cover cpu, ram or disk as a percentage. The disk rule follows whichever mount is fullest, so a bloated /var counts even when / looks fine. Rules have cooldowns (1 to 1440 minutes, 15 by default) and send recovery notices. Delivery is email or Telegram; you connect Telegram in settings and there is no bot server to host. You do configure this yourself: add a channel, write the rules.

Who monitors the monitor?

Self-hosted monitoring has a structural weakness, whatever the tool: the monitor runs on a box, and boxes die. Share a VPS between Kuma and the services it watches, and one dead host takes out both. Give Kuma its own VPS and that VPS is now the unmonitored server in your fleet. Either way there is no "Kuma is down" notification, because the sender is the thing that went down. You find out from a customer.

Fair credit: Kuma's push monitors are genuine dead-man's switches for your cron jobs. But nothing watches Kuma itself unless a second monitor somewhere else points at it, and then the same question moves one hop.

PulseNode answers this with architecture. The dashboard runs on our infrastructure; the agent pushes metrics out about every 30 seconds, and when the pushes stop, the agent-offline alert fires from our side. The server's silence is the trigger. You need a channel (an email or a Telegram chat ID) but no rule.

Uptime Kuma vs PulseNode, feature by feature

Sources: the Uptime Kuma README, releases, Docker monitor wiki and issue #2603, checked July 2026. PulseNode rows verified against the product.

The boring answer: run both

These tools cover each other's blind spots, so the practical setup for a small fleet is both: Kuma for endpoint checks and the status page, PulseNode for host health and resource alerts. If you searched for Uptime Kuma with server metrics, this pairing is the closest thing that exists. Who catches what:

• Nginx crashes at noon: Kuma's HTTP check fails and notifies you. PulseNode shows the host healthy, which points you at the app, not the box.
• Disk creeps to 92%: Kuma stays green because the site still serves. PulseNode's disk > 90% rule messages you before the partition fills.
• The VPS dies: Kuma reports the site down, provided Kuma lives somewhere else. PulseNode's agent-offline alert fires either way.

Hosted options: managed Kuma or hosted server monitoring

If you actually typed "hosted Uptime Kuma alternative", that exists. PikaPods runs open source apps as managed pods from ~$1.80/mo, and Elestio offers fully managed Uptime Kuma from $11/mo. Either removes the babysitting. Neither adds host metrics, because Kuma has none to add.

PulseNode has two flat plans, billed through Lemon Squeezy, VAT at checkout, cancel anytime:

• Hobby, €5/mo: 5 servers, 7-day history, dashboard and charts, cpu/ram/disk alerts to email and Telegram, agent-offline alerts, external HTTP(S) and TLS-expiry checks (dashboard status).
• Pro, €15/mo: 20 servers, 30-day history, 14d and 30d chart windows, everything in Hobby.

Get Hobby for €5/mo Get Pro for €15/mo

What PulseNode does not do

So you aren't surprised after paying:

• It is not free, not open source, and not self-hostable. Kuma is all three.
• No status pages. Kuma ships multiple, with domain mapping.
• External HTTP(S) and TLS-expiry checks are status only: up/down, latency and cert expiry on the dashboard, no notifications today. Kuma is strictly better for notification-backed external checks.
• The Docker panel is visibility only: status, image and uptime across servers, no alert when a container stops. Kuma can alert per container if you give it the Docker socket.
• Alert rules cover cpu, ram and disk percentages. There are no rules on network traffic or load average.
• No public API and no data export for customers today.
• Linux only (amd64 and arm64), with metrics about every 30 seconds. No Windows or macOS agent.
• It's a young product from one founder. Fixes ship fast, but support is one inbox.

Setup: both are quick, but only one stays your job

Kuma's install is genuinely easy. One Docker command and it's up:

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2

Without Docker you need Node.js 20.4 or newer plus Git and PM2, and the data directory must be a local volume (no NFS). Day one is easy. The recurring part is the deal: you apply updates and back up the data volume, and the host it runs on is yours to keep alive.

PulseNode's agent installs with one command: a single static Go binary run as a hardened systemd service. It pushes metrics out over HTTPS about every 30 seconds and never listens on a port, so there is no inbound firewall rule. The dashboard is not your job; that's what the subscription pays for.

See also

• All comparisons
• PulseNode vs Beszel: free, self-hosted server metrics.
• PulseNode vs Prometheus + Grafana: the full-stack route.
• How to get an alert before a Linux disk fills up
• PulseNode docs: agent install and alert setup.