A self-hosted Uptime Kuma alternative

Your status page is green. Your customers are emailing you anyway.

Uptime Kuma told you the site responds. It cannot tell you what the application said while it was responding badly, because it never sees your logs.

That is the whole difference between these two tools, and this page starts with the part where Uptime Kuma wins, because that part is long.

Start with the honest part

Uptime Kuma is free, MIT-licensed, and better at uptime monitoring than Central Logging is. Not slightly better. Better in most of the ways you would list if someone asked you to specify an uptime monitor.

It checks on 20-second intervals. Central Logging’s shortest interval is 60 seconds, and the picker offers 60, 120, 300 and 600 seconds — nothing else.

It monitors HTTP(S), TCP ports, ping, DNS records, WebSocket, Docker containers, push endpoints and more. Central Logging does a plain HTTP GET and nothing else.

It notifies through Telegram, Discord, Gotify, Slack, email over SMTP and, per its own README, “90+ notification services”. Central Logging has three: Slack, Telegram, Pushover. There is no email.

It has status pages with custom domains. Central Logging has none.

So if uptime monitoring is what you need, install Uptime Kuma. It is free, it is good, and nothing on this page is an argument against it.

The rest of this page is for people who are also going to run something for logs.

The honest part about our uptime checks

Before the comparison table, three things about Central Logging’s website monitoring that you would find out in week two, so you may as well find out now.

An HTTP error status does not raise an alert. A monitor pointed at a URL returning 500 records the 500 and stays quiet. The alert conditions are a connection failure, a keyword appearing or disappearing, and a TLS certificate expiring within seven days. A server that answers every request with a 500 is, as far as the alerting is concerned, up.

The workaround is the keyword check, and it is honestly a better health check anyway: point the monitor at a /healthz that prints ok only when the application is actually well, and alert when ok stops appearing. But you have to know to do that.

The request timeout is five seconds and you cannot change it. There is no field for it. An endpoint that takes six seconds under load is indistinguishable from one that is down.

The new-monitor form asks for a name and a URL only. Interval, keyword and alert condition are on the edit page. Create a monitor and walk away and you have a bare liveness check.

Uptime Kuma has none of these limits.

Side by side

Two rows are worth reading twice. The monitoring rows all favour Uptime Kuma. The log row is the only reason to read on.

The thing a status checker cannot do

Here is the sequence that makes people go looking for something else.

The alert fires at 03:14. The site was down for four minutes and came back on its own. Now you want to know why.

Uptime Kuma knows the request failed. It does not know that your database connection pool was exhausted, because the line saying so is in the application log on the server, and Uptime Kuma has never read a line of it.

So you SSH in, you run journalctl -u yourapp --since 03:10 --until 03:20, and you hope the journal still has it. If the box has already rotated, or if it was the box itself that went away, you get nothing.

In Central Logging the check history and the logs are in the same database, on the same clock. The uptime check that failed at 03:14 sits next to whatever the application logged at 03:14, because the application has been shipping its journal to the same server all along:

SELECT datetime("timestamp", 'unixepoch') AS at, msg
FROM logs
WHERE "timestamp" BETWEEN strftime('%s','2026-09-13 03:10:00')
                      AND strftime('%s','2026-09-13 03:20:00')
ORDER BY "timestamp";

That is the pitch. Not better uptime monitoring — worse uptime monitoring, with the logs attached.

Running both is a perfectly good answer

Nothing stops you. Uptime Kuma is free and runs in a container; Central Logging is one binary. Point Uptime Kuma at your sites and get its twenty-second checks and its status page, and point your servers’ journals at Central Logging and get search, SQL and alerting over what they said.

The reason people consolidate anyway is not features. It is that every additional self-hosted service is a thing to upgrade, back up, and remember the login for. Uptime Kuma needs Docker or a Node runtime and a process manager; Central Logging is one binary with no database to install. Whether removing one of those from your list is worth $187 is a judgement about your weekends, not about software.

What Central Logging adds, beyond logs

If you are weighing the consolidation, these come in the same binary and people routinely do not realise it:

• Cron job monitoring with learned schedules. Ping a URL when a job completes; it works out the job’s normal frequency from the last hundred pings and tells you when one is late. Nothing to declare. See cron monitoring.
• Host check-ins and inventory. Which servers are reporting, what is installed, what is running. Not CPU threshold alerting — liveness and inventory. See host monitoring.
• Prometheus scraping and charts, without running Prometheus and Grafana.
• SQL and full-text search over everything you ship it, with alert rules written as queries.

Things Uptime Kuma does that this does not

• Cost nothing. MIT licence, free forever.
• Check anything that is not HTTP. TCP, ping, DNS, WebSocket, Docker containers.
• Alert on HTTP status codes.
• Email and SMS, and roughly ninety other notification targets.
• Public status pages, on your own domain.
• Sub-minute checks, down to twenty seconds.
• Configurable timeouts and request methods.

Things Central Logging does that Uptime Kuma does not

• Store and search your logs. This is the only item on the list that matters, and it is the reason the page exists.
• Query them with SQL, including json_extract over structured lines.
• Alert on log content, not just on reachability.
• Monitor cron jobs without you declaring their schedules.
• Run as one binary with no container runtime, no Node, no process manager.

Who should choose which

Use Uptime Kuma if you want uptime monitoring. It is free, it is better at the job, and adding a log server does not change that.

Use Central Logging if you need somewhere to put your logs and you would rather the same process also watched your sites, your cron jobs and your servers, and you can live with 60-second HTTP checks that ignore status codes.

Use both if the twenty-second checks and the status page matter and you also want the logs. That is a legitimate answer and the most common one.

Weighing it against a hosted checker instead? The Uptime Robot comparison covers that side. If cron monitoring is the part you care about, Healthchecks.io and Cronitor are the closer comparisons.

Try it

The free download is the complete product, not a trial. Add one monitor and ship one server’s journal, and see whether having them in one place changes how you debug.

14-day refund if you buy and it does not fit.