---
title: "Monitor your websites with Uptime Kuma: from deploy to your first down alert"
description: "Deploy Uptime Kuma on Zenavo from the template, set up website and API checks, connect Telegram or email notifications, verify down and recovery alerts, and back up the data volume."
date: 2026-11-10
language: en
url: https://zenavo.app/blog/uptime-kuma-monitoring
---

# 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](https://github.com/louislam/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](https://docs.zenavo.app/servers/add-a-server) to Zenavo, then open the [Uptime Kuma template](https://zenavo.app/deploy?template=uptime-kuma), 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](https://docs.zenavo.app/networking/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](https://docs.zenavo.app/operations/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](https://github.com/louislam/uptime-kuma/releases) 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](https://zenavo.app/deploy?template=uptime-kuma): 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.