91.1k stars · MIT · 2.5.3 (2026-08-22) · Track this in Scout
Self-hosted uptime monitor with alerts and a status page — find out the site is down before a visitor does.
▶Repo detailsthe review · specs · pros & cons · install
What it is
A self-hosted uptime monitor. You give it a URL, a port, a container or a certificate to watch, it checks on a schedule you choose, and it shows you a history of response times plus an alert when something stops answering. It also publishes a status page you can point people at.
What it is good for. Edition 5 covered beszel and was explicit that it measures resources, not availability — it will tell you the box is at 92% memory, never that the landing page is returning a 502. That gap is the one that costs money. A campaign sends traffic over the following three days, and if the site is down for four hours in the middle of that window nobody finds out. Every campaign this radar has proposed is a spike of attention pointed at one small server, and attention that lands on an error page does not come back for a second try. There is a second use worth as much: watching TLS certificates and the PostgreSQL port, which is how you find out about the expiring certificate a week early instead of on the morning it breaks.
- Genuinely a fifteen-minute install: one container, a web form, done — the lowest-friction entry in this edition
- Ninety thousand stars and MIT, which for something whose entire job is to be reliable is the number that matters
- Notifies through ninety-plus channels including Telegram and ntfy (04), so the alert reaches you rather than a dashboard
- If it runs on the same box it is monitoring, a machine-level failure takes the monitor down with the site. The honest fix is a second cheap host or the free tier of a hosted checker as a backstop — worth ten minutes of thought before you install it
- It watches from one location, so it cannot tell you the site is unreachable from Moscow while it answers fine from the host it runs on
- Alert fatigue is real. Configure retries and a sensible interval on day one, or you will start ignoring it inside a fortnight, which is worse than not having it
There is a second use worth as much: watching your TLS certificates and your PostgreSQL port, which is how you find out about the expiring certificate a week early instead of on the morning it breaks.
docker run -d --restart=always -p 3001:3001 \ -v uptime-kuma:/app/data --name uptime-kuma \ louislam/uptime-kuma:2 # then open http://your-server:3001 and add the first monitor
