What it is
Uptime Kuma is an open-source monitoring tool. You give it a list of things to check, such as websites, mail ports, DNS records or certificates, and how often. It checks them on schedule, keeps a history, draws a status page, and sends an alert when something fails.
It is deliberately simple. It is not a full observability platform with metrics, traces and log search. It answers one question very well: is this working right now, from the outside, the way a visitor would see it?
Why I run it instead of the SaaS alternative
Hosted monitors such as UptimeRobot, Pingdom or Better Stack are good, and they have one real advantage: they check from outside your own network, from several places at once. If your whole server is down, a monitor running on that server cannot tell anyone. That is a fair point and I do not dismiss it.
I run Uptime Kuma because I want every site checked properly, not just pinged. Most monitors, by default, count a site as up if the server answers with a success code. That is how a site can show green for days while serving an error page, a blank screen or a login that never loads. Every check here looks for real text that should be on the page. If the text is not there, the site is down, whatever the server claims.
Self-hosting also means there is no per-monitor limit, so every site and every service is in, not just the important few.
How it is set up here
- Every site, every five minutes. Each site on the estate has a probe that runs every five minutes.
- Content checks, not status codes. Each probe looks for a specific piece of text that only appears when the page has rendered properly.
- Certificate expiry watched. Certificates are checked for how long they have left, and a separate daily sweep covers every certificate on the estate.
- Alerts that reach a human. Failures go to Slack, which reaches my phone. An alert that lands in an inbox nobody reads is not monitoring.
- A second line of checks. A scripted daily health check runs dozens of further tests across the estate, again judging content rather than status codes, so a quiet failure the probes miss still gets caught.
What it replaces
- Hosted uptime services that charge per monitor or limit check frequency.
- Finding out a site was down because a customer emailed.
- Certificates that expire on a Saturday because nobody had the date written down.
What it costs to run is very little: a small container and the discipline to add a check every time a new service goes live. The second part is where most monitoring quietly falls behind.
What I would do for a client
Start by listing what you run and what currently watches it. In most estates there are services nobody monitors at all, and many more where the monitor only checks that a server answers. The audit shows both.
Then build monitoring that tells the truth: content checks on every public site and every internal tool that matters, certificate expiry tracked across the estate, alerts routed to the people who can act on them, and at least one check from outside your own network so a total outage is still reported. Uptime Kuma is a good fit for much of that. Where you already pay for a monitoring platform, I would configure it to check the same way rather than add another tool.
Questions people ask
Why five minutes and not every minute?
Five minutes catches real outages quickly without hammering every site constantly. For a service where a minute matters, the interval can be shorter.
What is a content check, exactly?
The monitor loads the page and looks for a phrase that only appears when everything worked: a heading, a footer line, a login form. An error page, a blank page or a default server page will not contain it.
Who watches the monitor?
That is the right question. The daily health check is a separate system, and the alerts go to a phone, not a dashboard someone has to remember to open.
Can customers see a status page?
Yes. Uptime Kuma can publish a public status page for whichever services you choose.