Uptime Kuma

What is Uptime Kuma?

Uptime Kuma is a self-hosted uptime monitoring tool with a clean interface. It checks HTTP, TCP, ping and keyword endpoints, sends notifications through dozens of channels, and provides status pages — a lightweight alternative to paid monitoring services.

Best for

Anyone monitoring their own sites and servers on a budget

Why choose Uptime Kuma

Uptime Kuma is the monitoring tool that people actually keep running. It watches your services — HTTP endpoints, TCP ports, pings, DNS records, even page content for a specific keyword — and alerts you when something breaks, through more notification channels than you will ever need. It also serves public status pages, which is the feature that makes it valuable beyond personal use: you can point clients or users at a page that shows what is up without exposing anything else.

Replaces

• UptimeRobot
• Pingdom
• Better Stack

Key features

• HTTP, TCP, ping and keyword monitors
• 90+ notification channels
• Public status pages
• Multi-language support

What to watch out for

Alerts are only useful if you configure them to be. An instance set up carelessly will either stay silent through an outage or wake you at three in the morning because a single packet was dropped; getting thresholds and retries right takes an evening of tuning. It also has no built-in redundancy — the monitoring server is itself a service that can go down, and if it does you learn nothing. External checks, meaning monitoring from more than one location, are outside its scope.

How to deploy

• Docker
• Node.js

Getting started

Deploy with Docker and give it a persistent volume, since all monitors and history live in its SQLite database. Configure at least two notification channels of different kinds so a failure in one does not leave you blind. Set the retry count above one before considering a service down, and start every monitor in an unannounced state to learn its normal behaviour. Create a status page for anything you have promised someone else, and back up the database on a schedule — losing it loses your entire monitoring history.

Typical setup

It sits on a small always-on machine — often the same server it is monitoring, which is a known weakness — with a persistent volume for its SQLite database. Monitors are created for websites, APIs, ports and certificates, and notifications go to at least two channels of different kinds. Public status pages are commonly enabled for anything with an audience, and the database is included in the backup routine because losing it loses all history.

Who should look elsewhere

Not a complete monitoring strategy by itself. If the machine it runs on fails, it tells you nothing, and it cannot check from outside your own network — which is exactly what you need when the problem is the network. It is also a poor fit for anyone who will not tune alert thresholds, because a noisy monitor gets muted and a muted monitor is worse than none.

Project health

• GitHub stars: 91,997
• Last code push: 2026-10-01
• Open issues: 827
• Status: actively developed

Figures pulled from the GitHub API and refreshed periodically.