Compare / Uptime Kuma / 30 August 2026

Uptime Kuma’s status page, and when to put Pharos in front of it

Uptime Kuma is a very good monitor, and it ships a status page. If you are here because that page does not do what your customers need, the answer is usually not to replace Kuma. It is to keep Kuma watching and let Pharos do the publishing — Pharos takes Kuma’s results as a heartbeat, with an additional adapter. This page says what each tool does, where the line is, and when Kuma alone is the right call.

What Uptime Kuma is good at

Kuma is a self-hosted Node.js monitor. It polls HTTP, TCP, ping, DNS and Docker containers among many other probe types, accepts push monitors from jobs that call in, and can tell you about a failure through dozens of notification services. The dashboard is quick, the community is large, and the licence is MIT. For a developer or a small team, it is often the first monitoring tool that actually gets used.

Its status page is a view onto those monitors. Monitor status shows up automatically; incident notes are something a person writes. There are no e-mail subscribers, no incident timeline that a check writes for you, and no API that scripts written against Cachet can talk to. That is not a flaw — the status page is a feature of a monitor, not the product — but it is the point where people start looking for something else.

What Pharos is

Pharos is a status page first. Its own checks — HTTP, TCP and heartbeat — are there so a small installation needs no second tool, not to compete with Kuma on probe types. What it puts its effort into is the part your customers see:

• Incidents that write themselves. A check that fails twice opens an incident and posts the first update; three healthy checks close it and post the last one. Incidents you open by hand are never closed by a check.
• One incident across several components, each with its own status, with impact stored separately for whatever consumes the outgoing webhook.
• Subscribers. A Get notified button, double opt-in, one mail per update, one-click unsubscribe, sent through your own SMTP from the same cron line as the checks.
• Every section is a switch. Banner, uptime bar, services list, per-component bars, incident history, empty days, subscribe button, API link — with a live preview of the real page before you save.
• A Cachet-shaped API (components, incidents), an HMAC-signed outgoing webhook for n8n, and Zabbix or Grafana through the same API.
• It runs on PHP. PHP 8.3, SQLite by default, one cron line — cPanel, DirectAdmin, Plesk, compatible PHP hosting, or Docker. No daemon.

What each does

Comparison based on public information, August 2026. “Uptime Kuma” is a trademark of its owner, used here only to identify the product compared.

Using both: Kuma watches, Pharos publishes

Kuma is wired into Pharos as a heartbeat rather than a separate integration, which means a separate adapter or API workflow is required. The documentation explains this limitation. The adapter must satisfy these requirements:

1. Create a Pharos component with source Heartbeat and save it.
2. Copy the heartbeat URL from the component form, or from Integrations. It looks like /api/v1/heartbeat/hb_…; the unguessable path is the credential, so Kuma needs no token.
3. In Kuma, use a separately configured adapter to call that URL periodically after successful checks.
4. Set the Pharos interval to match how often Kuma reports.

Silence for two intervals turns the component red and opens an incident. When Kuma starts calling in again, three healthy checks in a row close it. A Kuma monitor on a one-minute schedule wants a Pharos interval of 60, which gives it a two-minute grace period before anything turns red — one dropped call should not publish an outage.

Two things to keep straight. Pick one owner per component: a Pharos component fed by Kuma should have no built-in check of its own, or the two will overwrite each other every minute. And Pharos still counts uptime from what it hears, so a component created yesterday shows 89 grey days on the 90-day bar; grey means no data, not fine.

Where Kuma alone is the better choice

If you are the only person who reads the page, Kuma is enough. Its status page is fine for a team dashboard, and adding a second application to publish the same information is work for nobody. If you need ping, DNS or Docker checks, Kuma has them and Pharos does not. If your alerting lives in Telegram, Discord or PagerDuty rather than in a customer’s inbox, Kuma’s notification list is the reason to keep it. And if a Node.js container is already part of your stack, the fact that Pharos runs on a PHP host without one does not matter to you.

Where Pharos earns its place is when the page has an audience: customers who want to subscribe, a brand that has to be on it, incidents that must be written down without a person typing, or scripts that already speak Cachet. Then the honest layout is Kuma for the watching and Pharos for the telling — and if the setup is small enough, Pharos’s own checks may be all you need.

Questions people ask

Does Pharos replace Uptime Kuma?

No, and it does not try to. Kuma is a monitor with far more probe types and notification channels than Pharos will ever have. Pharos is the customer-facing page: incidents, subscribers, branding, a Cachet-compatible API. Kuma can feed it.

How does Kuma talk to Pharos?

As a heartbeat. You create a Pharos component with source Heartbeat, copy its URL, and configure an adapter to call that URL periodically after successful checks. If the calls stop for two intervals, the component goes red and an incident opens by itself.

Can Pharos check things without Kuma?

Yes. It has its own HTTP, TCP and heartbeat checks that run from one cron line, so a small setup needs no second tool at all.

Does Pharos need a VPS like Kuma does?

No. Pharos is a PHP 8.3 application with SQLite by default, so it runs on a cPanel, DirectAdmin or Plesk account, compatible PHP hosting, or Docker. Kuma is a Node.js service, which usually means Docker or a VPS.

Install Pharos   Releases & downloads