Uptime Monitoring for a Small Website With Uptime Kuma

Your site went down on Saturday night and you found out on Monday from a customer email. Uptime monitoring exists to close that gap, and for a small website or home server you do not need a paid service to get it. This walkthrough sets up Uptime Kuma, a free self-hosted monitor, in about 30 minutes, with alerts that reach your phone and checks that catch the failures that matter, including expiring certificates.

What you need before you start

A small Linux machine with Docker installed. A 5 dollar VPS with 1 vCPU and 1 GB of RAM is plenty for 50 monitors.
Ideally, a machine that is not the one you are monitoring. More on that below.
A status subdomain on your own domain, if you want a public status page.
An alert channel: a Telegram bot, a Discord or Slack webhook, an ntfy topic, or SMTP credentials for email.

Uptime Kuma uses roughly 100 to 150 MB of RAM in normal use. Storage grows slowly; a year of history for 20 monitors at 60 second intervals stays well under 1 GB.

Install Uptime Kuma with Docker Compose

Create a folder called uptime-kuma in your home directory and add a compose.yaml file with a single service. The settings you need are:

image: louislam/uptime-kuma:1
restart: unless-stopped
ports: 127.0.0.1:3001:3001, so the dashboard only listens locally and your reverse proxy handles public access
volumes: ./data:/app/data, so monitors and history survive upgrades

Then run docker compose up -d from that folder. After a few seconds, check docker compose ps to confirm the container is healthy.

Point your reverse proxy at 127.0.0.1:3001 for the status subdomain and let it handle TLS. If you have not picked a proxy yet, choosing a reverse proxy for a home server without headaches compares Caddy, Nginx, and Traefik for exactly this kind of setup. Uptime Kuma uses WebSockets, so make sure your proxy passes the Upgrade header; Caddy does this by default.

Open the subdomain in a browser and create the admin account straight away. Until you do, anyone who finds the URL can claim it. The 1.x image stores everything in a single SQLite file inside the data folder, which keeps backups simple. Then set the correct time zone under Settings, then General, so incident timestamps match your logs.

Set up your first uptime monitoring checks

Click "Add New Monitor". You will use three monitor types for most small sites.

HTTP(s) monitor for the website

Monitor type: HTTP(s).
URL: the full address of a page that exercises your app, not just the homepage if the homepage is cached.
Heartbeat interval: 60 seconds.
Retries: 2. This means three consecutive failures, about three minutes, before you get an alert.
Turn on "Certificate Expiry Notification". Kuma will warn you 21, 14, and 7 days before the TLS certificate expires.

HTTP(s) keyword monitor for real content

A server can return status 200 with an error page or an empty template. Use the keyword type and pick a word that only appears when the page rendered properly, such as a footer phrase or product name. This catches broken database connections that a plain HTTP check misses.

TCP or DNS monitors for everything else

Use TCP Port checks for mail (ports 25, 465, 587, 993) and SSH. Use a DNS monitor for your main domain's A record and MX records. If your domain's renewal ever lapses, the DNS monitor fails quickly, which ties in with the steps in expired domain recovery steps before your email goes dark.

Alerts that wake you only when it matters

Open Settings, then Notifications, and add at least one channel. Two good free choices:

Telegram: create a bot with BotFather, paste the token and your chat ID, then press Test.
ntfy: pick an unguessable topic name, subscribe to it in the ntfy phone app, and enter the topic in Kuma.

Add email as a second channel so one service outage does not hide another. Then apply the notification to each monitor, or tick "Default enabled" so new monitors get it automatically.

Tune noise early. A monitor that pings you for every 20 second blip trains you to ignore it. Use retries of 2 or 3, set a longer interval of 5 minutes for low-priority checks like a staging site, and use maintenance windows during planned upgrades so you do not get paged for your own work.

Why you should not host the monitor on the same server

Many tutorials install Uptime Kuma on the same machine as the website, because it is convenient and the box is already there. That gives you a monitor that goes down at the same moment as the thing it monitors. Power loss, a full disk, a kernel panic, or a network outage at the provider will silence both, and you will get no alert at all.

The fix is cheap. Run Kuma on a separate small VPS with a different provider or region, or on a Raspberry Pi at home if your site lives in the cloud. If you only have one machine, at least add a free external check from a hosted service as a backstop that watches the Kuma instance itself.

The same thinking applies to alerts. If all notifications go through email on the server being monitored, a mail outage hides every other alert. Keep at least one channel completely independent.

A public status page and routine upkeep

Under Status Pages, create a page, give it a slug, and add the monitors visitors care about, such as Website, API, and Email. Leave out internal checks like SSH. Point your status subdomain at it in Kuma's settings. During an incident, post a short update on the page; it saves you answering the same email twenty times.

For upkeep:

Back up the data folder weekly. It contains a SQLite database with all monitors and history.
Update monthly with docker compose pull followed by docker compose up -d.
Turn on two-factor authentication for the admin account under Settings, then Security.
Review monitors every quarter and delete any for services you have retired.

If the Kuma host also runs other services, the hardening in SSH key authentication setup for a small Linux server is worth applying before you expose the dashboard.

Frequently asked questions

Is Uptime Kuma free to use?

Yes. Uptime Kuma is open source and free to self-host, with no limit on monitors. Your only cost is the machine it runs on, which can be a 5 dollar VPS or a spare Raspberry Pi.

How often should uptime monitoring check a website?

For most small sites, every 60 seconds with 2 retries is a good balance. You hear about a real outage within about three minutes without getting alerts for brief network blips. Low-priority services can be checked every 5 minutes.

Can Uptime Kuma monitor SSL certificate expiry?

Yes. Turn on certificate expiry notification in an HTTP(s) monitor and Kuma warns you before the certificate expires, by default at 21, 14, and 7 days. This catches failed automatic renewals before visitors see a browser warning.