Set Up Uptime Kuma as a Self-Hosted Status Page Monitor

Why Self-Hosted Uptime Monitoring Makes Sense

Most hosted monitoring services give you a dashboard, a handful of monitors, and a bill that climbs the moment you need more than the basics. Uptime Kuma takes a different approach: it runs entirely on your own server, stores nothing in someone else’s cloud, and offers a polished, real-time status interface that rivals paid alternatives. For developers, sysadmins, and self-hosters who manage multiple services or expose internal tools to a team, that combination is hard to ignore.

The setup process is straightforward enough that you can have monitors running within the hour, but there are enough configuration options – notification channels, custom status pages, certificate expiry checks, Docker container monitoring – that it rewards spending extra time with it. This guide walks through the full process: installation via Docker, initial configuration, monitor setup, and publishing a public-facing status page.

Installing Uptime Kuma with Docker

Docker is the fastest and cleanest way to run Uptime Kuma. Before starting, make sure Docker and Docker Compose are installed on your server. A basic Linux VPS running Ubuntu 22.04 or Debian 12 works well. You will also want a domain name or subdomain pointed at your server if you plan to expose the status page publicly.

Create a directory for the project and add a docker-compose.yml file with the following content:

version: "3"
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    container_name: uptime-kuma
    volumes:
      - ./uptime-kuma-data:/app/data
    ports:
      - "3001:3001"
    restart: unless-stopped

Run docker compose up -d from that directory. Docker will pull the image and start the container. Within seconds, Uptime Kuma is accessible at http://your-server-ip:3001. On first load, you will be prompted to create an admin username and password – do this immediately, since the setup screen is open to anyone who reaches the port before you lock it down.

For production use, you will want a reverse proxy sitting in front of port 3001 so you can serve Uptime Kuma over HTTPS on a clean subdomain like status.yourdomain.com. Nginx and Caddy both work well here – if you are already running Caddy as a self-hosted reverse proxy with SSL, adding Uptime Kuma as a new site block takes under five minutes and handles certificate issuance automatically.

Adding Monitors and Configuring Alerts

Once you are logged in, the main dashboard greets you with a clean sidebar and a large empty canvas – that changes fast. Click Add New Monitor to open the monitor creation panel. Uptime Kuma supports HTTP/HTTPS checks, TCP port checks, ping, DNS resolution, Docker container status, and a handful of more specialized types including Steam game server queries and Minecraft server checks.

For a standard web service, select HTTP(S) as the monitor type, paste in your URL, and set the check interval. The default is 60 seconds, which is reasonable for most use cases. You can also configure the expected status code – useful if a service returns a 301 redirect that you want flagged rather than treated as healthy. The Heartbeat Interval and Retry fields let you reduce false positives by requiring a service to fail multiple consecutive checks before triggering an alert.

Notification setup lives under Settings > Notifications. Uptime Kuma supports a wide range of channels out of the box: Slack, Discord, Telegram, email via SMTP, PagerDuty, Pushover, Gotify, and more than 90 others. Each notification provider has its own configuration fields – for a Telegram bot, you will need a bot token and chat ID; for Slack, an incoming webhook URL. After saving a notification method, you can test it directly from the settings panel before attaching it to any monitor.

Once a notification channel is saved, go back to any monitor and expand the Notifications section to attach it. You can attach multiple channels to a single monitor – for example, sending a Telegram message for all failures while reserving PagerDuty for critical production services. Monitors can also be grouped with tags, which makes filtering easier when you are watching dozens of services at once.

Setting Up a Public Status Page

The status page feature is where Uptime Kuma earns its place as a full monitoring solution rather than just a private dashboard. Navigate to Status Pages in the left sidebar and click New Status Page. Give it a slug – this becomes the URL path, such as /status – and a display title. You can then add individual monitors to the page, organize them into groups, and write a description that appears at the top of the page.

The status page itself is publicly accessible without login, which is exactly the point – you share the link with users or teammates so they can check service health without needing access to your admin panel. Custom domain support lets you map it to something like status.yourcompany.com by setting the domain field in the status page settings and pointing DNS accordingly through your reverse proxy. The page shows live uptime percentages, 90-day history bars, and current incident status, all updating in real time over a WebSocket connection.

Advanced Options Worth Knowing

Uptime Kuma includes SSL certificate expiry monitoring built into every HTTPS monitor. By default, it will alert you when a certificate is within 30 days of expiry. You can adjust that threshold per monitor, which is useful if you run services with short-lived certificates issued every 90 days and want alerts only when something fails to renew rather than as a routine reminder.

The Maintenance feature, found in the sidebar, lets you schedule downtime windows that suppress alerts and display a maintenance banner on your status page. This prevents a flood of notifications during planned work and keeps your public status page accurate rather than showing false outages. You can set maintenance windows as one-time events or recurring on a schedule.

For users running a lot of Docker containers on the same host, the Docker monitor type connects directly to the Docker socket and reports container state – running, stopped, restarting – without needing to expose any additional ports. This requires mounting the Docker socket into the Uptime Kuma container by adding – /var/run/docker.sock:/var/run/docker.sock:ro to the volumes section of your compose file. It is a read-only mount, so Uptime Kuma can observe containers but cannot control them, which keeps the security footprint minimal. If your host runs ten or fifteen containers, this single addition can replace a lot of manual checking.

Keeping Uptime Kuma Updated and Backed Up

Uptime Kuma receives regular updates, and pulling the latest image is straightforward with Docker: run docker compose pull followed by docker compose up -d. The project follows semantic versioning, and breaking changes are rare between minor releases, but checking the GitHub release notes before updating takes thirty seconds and prevents surprises.

All persistent data – monitor configurations, notification settings, status page definitions, and historical uptime data – lives in the volume you mapped to ./uptime-kuma-data. Backing up that directory on a schedule is enough to restore the entire instance. If you are running this on a VPS, copying that folder to an offsite location weekly is sufficient for most setups. Because there is no external database to manage, the backup process is a single directory copy rather than a database dump and restore workflow.