Skip to main content
Monitor sites and services with alerts and a public status page. The template runs Uptime Kuma 2.5.8 (slim variant, SQLite). Your data stays on your own app.

​
What it creates

One app (image) that comes up ready, with no questions. It uses little memory (about 120 MiB idle); 512 MB is the minimum of a web app. It needs a plan with Docker images and one free image slot; see Plans and limits.

​
First steps

1

Create the administrator

Open the address right after the deploy. Uptime Kuma asks for a user and a password on the first visit, and whoever opens it first creates the account.
2

Create the first monitor

Add New Monitor: type (HTTP(S), TCP, Ping, DNS, keyword, JSON and others), name, target and interval. The minimum is 20 seconds; 60 seconds is enough for most sites.
3

Connect an alert

Settings > Notifications > Setup Notification. For Telegram, create a bot with @BotFather and enter the token and the chat id. Tick Default enabled so every new monitor uses the channel. Discord, Slack, email (SMTP), webhook and many others work the same way.
4

Publish a status page

Status Pages > New Status Page, choose the short address (/status/<name>), add the monitors and save. The page is public and asks for no login. To use your own domain, add it in the app’s Domains and enter it in the status page under Domain Names.

​
Push monitor for scheduled jobs

For cron jobs and backups, create a Push monitor. Kuma generates a URL: make the job call it on every run. If the job stops calling within the interval, the monitor goes down and the alert fires.

​
Variables

​
Limits and good practice

  • The Real Browser monitor is not available: the image has no browser.
  • SQLite only. For thousands of monitors, prefer another setup.
  • There is no Docker container monitor.
  • Checks start from one place, your app’s server, so a “down” alert reflects that server’s route to the target.
  • Zero-downtime deploy is off: two copies on the same database would run every monitor twice and send duplicate alerts.
  • The data (/app/data/kuma.db) is part of the app’s snapshots. Kuma migrates its database on update, so a rollback returns with the data. Old history is deleted after 180 days by default (Settings > Monitor History).

​
Common problems

  • Someone created the administrator before me. Delete the data in /app/data with the file manager and restart to start over, or restore an earlier snapshot.
  • The Ping monitor does not answer. ping runs without privileges and some targets filter ICMP. Use a TCP or HTTP monitor.
  • Duplicate alerts. Keep a single copy of the app.

​
License

Uptime Kuma is distributed under the MIT license. The listing does not imply endorsement by the project. See also the other official templates.
Last modified on October 28, 2026