Uptime Kuma checks your sites and services on a schedule and alerts you the moment one stops responding. It is free, runs in one container, and needs very little memory.
1. Start the container
This assumes Docker is already installed; our Docker guide covers that.
$ docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2The -v uptime-kuma:/app/data part stores your monitors, history, and settings in a Docker volume, so they survive an update or a container rebuild.
Open http://YOUR.SERVER.IP:3001 and create your admin account. The first account you create is the administrator, so do this immediately after starting the container.
2. Add your first monitor
Click Add New Monitor. The settings that matter:
- Monitor Type: HTTP(s) for a website, TCP Port for a service like a mail or game server, Ping for a plain reachability check.
- URL or hostname: what to check.
- Heartbeat Interval: 60 seconds is a sensible default. Shorter intervals mean faster alerts and more requests to your own site.
- Retries: 1 or 2. This stops a single dropped packet from waking you up.
Save, and the monitor starts checking right away.
3. Set up alerts
A monitor with no notification channel is just a dashboard. Open Settings, then Notifications, and add a channel. Telegram is the quickest: create a bot with @BotFather in Telegram, paste the token and your chat ID, and send a test message from the same screen. Email through SMTP, Discord, Slack, and webhooks all work the same way.
Attach the notification to your monitors, either on each monitor or with Default enabled so new monitors use it automatically.
4. Monitor more than websites
Uptime Kuma is not limited to HTTP. Useful checks for a server:
- A TCP Port monitor on 22 tells you SSH is alive even when the web server is not.
- A TCP Port monitor on 25 or 587 for a mail server.
- A Push monitor for jobs that should run on a schedule: your backup script calls the given URL when it finishes, and Uptime Kuma alerts you if the call does not arrive in time. That catches a silent backup failure, which is the worst kind.
5. Put it behind HTTPS
Do not leave port 3001 open to the internet. Bind it to localhost and put Nginx in front:
$ docker stop uptime-kuma && docker rm uptime-kuma $ docker run -d --restart=always -p 127.0.0.1:3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:2
Your data is in the volume, so recreating the container changes nothing else. Then proxy it with Nginx and get a certificate; our Nginx and Let's Encrypt guide has the config. Uptime Kuma uses WebSockets, so the Upgrade and Connection headers in that config are required here, not optional.
Do not monitor a server from itself
If Uptime Kuma runs on the same server as your website, it cannot tell you when that server goes down, because it goes down too. Run it on a second server, ideally in another location, and let it watch the first one. A cheap small plan is enough.
6. Publish a status page
Status Pages, then New Status Page, lets you pick monitors to show publicly and give the page its own address. It is a simple way to tell users about an outage without answering the same question twenty times.
7. Updating
$ docker pull louislam/uptime-kuma:2 $ docker stop uptime-kuma && docker rm uptime-kuma
Then run the same docker run command again. The volume keeps everything.
Quick reference
| Task | Where |
|---|---|
| Start | docker run ... louislam/uptime-kuma:2 |
| First login | http://SERVER:3001, first account is admin |
| Alerts | Settings, Notifications |
| Check a job ran | Push monitor type |
| Public page | Status Pages, New Status Page |
| Update | docker pull, remove container, run again |
Where to go next
Put the monitor on a different server from the things it watches. Then add checks for backups, cron jobs, and mail. Those fail without any visible symptom, so a monitor is the only way you find out.