Monitor your websites with Uptime Kuma: from deploy to your first down alert

Once a website or API is live, you shouldn't have to hear from a user that it's down. A monitor can check your endpoints every minute and alert you as soon as a certificate is expiring or a service stops responding.

Uptime Kuma is a lightweight open-source monitoring tool: it checks HTTP(s), keywords, TCP ports, DNS records and TLS certificate expiry, includes public status pages, and supports dozens of notification channels (Telegram, Slack, Discord, email, webhooks and more). This guide uses Zenavo's Uptime Kuma template to go from deployment to receiving your first real alert.

Where to run your monitor

Before deploying, decide which server should run Uptime Kuma:

• On the same server as your apps: fine when you're getting started. If a single container crashes or a certificate is about to expire, Uptime Kuma will still alert you; if the whole server loses power or networking, the monitor goes down with it.
• On a separate small server: better for production. Uptime Kuma uses very little memory, and running it on another server ensures you still get notified when your main server goes offline.

Deploy from the template

First connect a Linux server to Zenavo, then open the Uptime Kuma template, choose the server and deploy.

The template currently sets:

Setting	Value or purpose
Image	louislam/uptime-kuma:1
HTTP port	3001
Volume	/app/data: the SQLite database, monitors, check history and notification credentials live here

On the uptime-kuma service's Networking tab, bind a domain such as status.example.com to port 3001, add a DNS A record pointing to the server, and wait for HTTPS. See Domains for the steps.

Open the site and create your admin account as soon as the domain is live. The first visitor gets to set the admin username and password, so finish that right away.

Add your first monitor

After signing in, click Add New Monitor at the top left. A good starting setup:

Field	Suggestion
Monitor Type	HTTP(s) for a web page or API; HTTP(s) - Keyword to verify a specific word appears in the response
Friendly Name	Include the environment and target, such as Production - Home or API - /healthz
URL	The full https:// address users actually visit
Heartbeat Interval	60 seconds
Retries	2 or 3, so a single brief network hiccup doesn't wake you up at night
Certificate Expiry Notification	Enable it to get warned 7–14 days before a TLS certificate expires

If your app depends on a database, add a second monitor pointing at a lightweight health endpoint (such as /healthz) so you catch database connection failures as well as web server crashes.

Set up notifications and run a real drill

Open Settings → Notifications from the top-right profile menu, or click Setup Notification while editing a monitor:

1. Pick your channel (such as Telegram, Slack, Discord, SMTP email or a webhook) and fill in the token or credentials.
2. Click Test and confirm the test message arrives on your phone or in your inbox.
3. Turn on Default enabled, or toggle this notification channel on inside the monitor itself, and save the monitor (it's easy to click Test, see the message, and forget to attach the channel to the monitor).

To be sure alerts fire when an outage actually happens, run a quick drill against a test service:

1. Add a monitor for a non-production test service and wait for it to turn green (Up).
2. Stop that test service in Zenavo, wait 1–3 minutes (depending on your interval and retries), and confirm the monitor turns red (Down) and sends a down alert.
3. Start the test service again and confirm the recovery (Up) alert arrives.

Public status pages (optional)

If you want a public page like status.example.com/status/main for your users, click Status Pages in the top bar, create one, and add only the monitors you want the public to see. Leave internal admin tools, databases and private endpoints off public status pages.

Back up and upgrade

All monitors, notification credentials and uptime history live in the /app/data volume. Back it up from the uptime-kuma service's Backup & Restore tab:

1. Stop the project (volume backups require the project to be stopped).
2. Create the backup, then start the project again.
3. Download a copy to keep (it holds your notification bot tokens and webhook URLs, so store it securely). See Backups.

The template pins louislam/uptime-kuma:1 (the v1 major series). Before upgrading to a new major version, read Uptime Kuma's release notes and back up /app/data first; once a new major version migrates the database, switching the image tag back won't downgrade the data, so you'll need the pre-upgrade backup if you want to roll back.

FAQ

The "Test" button sent a message, but I didn't get an alert when a service went down? Edit the monitor and check the Notifications list on the right: make sure your notification channel is toggled on for that monitor, then click Save at the bottom.

Do I need to mount the host's Docker socket? No. HTTP(s) and TCP port checks cover almost every web app and database without granting the container access to docker.sock. To check another service in the same Zenavo project without going over the public internet, use its private hostname (such as http://api.zenavo.internal:3000/healthz).

I'm getting too many false alarms from brief blips? Increase Retries on the monitor from 0 to 2 or 3, and raise the request timeout slightly so Uptime Kuma only alerts when a check fails several times in a row.

Start from the Uptime Kuma template: bind your domain, create the admin account, attach your notification channel, and run one down-and-recovery drill so you know alerts will reach you when it counts.