Why Run Your Own Status Page
Most developers and homelab enthusiasts discover uptime monitoring the same way – something breaks, nobody notices for hours, and the post-mortem starts with “we had no visibility.” Commercial monitoring services solve this, but they come with monthly fees, data leaving your network, and alert limits that scale up in price right when you actually need them. Uptime Kuma changes that calculation entirely by giving you a full-featured, self-hosted monitoring dashboard that you control completely.
Uptime Kuma is an open-source monitoring tool built with Node.js and Vue.js. It watches your websites, APIs, TCP ports, DNS records, and more – then sends alerts through Telegram, Slack, Discord, email, and dozens of other channels when something goes down. It also generates a public-facing status page you can share with users or clients, all without routing a single byte through a third-party service. Getting it running takes less than fifteen minutes if Docker is already on your machine.
Prerequisites and Installation via Docker
You will need a Linux server or VM with Docker and Docker Compose installed. A small VPS with 1GB of RAM handles Uptime Kuma without any trouble, and so does a Raspberry Pi 4 or any modest homelab machine. If you want the status page accessible from outside your home network, a domain name pointed at your server makes the setup significantly cleaner – and pairing it with a reverse proxy like Nginx Proxy Manager lets you put Uptime Kuma behind HTTPS without touching raw Nginx config files.
Start by creating a directory for the project and writing a docker-compose.yml file. The official image is louislam/uptime-kuma:1 and the container exposes port 3001 by default. Here is a minimal but complete compose file:
version: '3.8'
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: always
ports:
- "3001:3001"
volumes:
- ./data:/app/data
Run docker compose up -d from that directory and Docker pulls the image, creates the container, and mounts a local data folder where Uptime Kuma stores its SQLite database. Visit http://your-server-ip:3001 in a browser and the first-run screen asks you to create an admin username and password. That account is local – no registration, no email verification, no cloud sync required.
Adding Your First Monitors
After logging in, the dashboard is empty and waiting. Click Add New Monitor in the upper left and a side panel opens with all available monitor types. For a standard website check, select HTTP(s), paste the URL, set a friendly display name, and choose a check interval. The default interval is 60 seconds, which is reasonable for most use cases. You can drop it to 20 seconds for critical services or raise it to five minutes for low-priority endpoints where you are more concerned about long-term availability than instant detection.
The monitor configuration panel has more depth than the clean interface suggests. You can define an accepted status code range so that a 301 redirect does not trigger a false alert. You can set a keyword that must appear in the response body – useful for catching pages that return 200 but serve an error message in the HTML. There is also a certificate expiry check built directly into HTTPS monitors, which sends an alert a configurable number of days before your TLS cert expires. For non-web services, the TCP Port monitor type works well for databases, game servers, or any service that opens a raw socket.
Configuring Notifications and the Public Status Page
A monitor that goes down silently is only marginally better than no monitoring at all. Uptime Kuma handles notifications through a system it calls notification channels, configured separately from individual monitors so you can reuse the same channel across dozens of services. Go to Settings, then Notifications, click Setup Notification, and choose from over 90 providers listed in the dropdown. Telegram is the fastest to configure – you need a bot token from BotFather and your Telegram chat ID, both obtainable in under three minutes. Discord and Slack webhooks are similarly straightforward.
Once a notification channel exists, attach it to a monitor by editing that monitor and scrolling to the notification section at the bottom of the form. You can attach multiple channels to a single monitor, which is worth doing for anything production-facing. Set the heartbeat notification option if you want a confirmation ping when a previously down service comes back up – that recovery alert is often more useful than the initial down notification because it closes the incident without requiring you to keep checking the dashboard manually.
The status page feature sits under its own section in the left sidebar. Create a new status page, give it a slug that becomes the URL path, then drag monitors from your list into the page layout. You can group monitors under category headers, write a custom description, and upload a logo. The finished page at http://your-server-ip:3001/status/your-slug shows green or red indicators for each service and a 90-day uptime bar at the bottom. Visitors see nothing about your server infrastructure – just service names and availability data you choose to display.
If that status page needs to be publicly accessible while the main Uptime Kuma dashboard stays private, reverse proxy rules solve this cleanly. Route your domain to port 3001 and restrict access to the /status/ path for public visitors, leaving the dashboard login as the only entry point for everything else. Some teams go further and set up a second subdomain exclusively for the status page, keeping the monitoring backend on a completely separate hostname that never appears in public DNS at all. Whether that level of separation matters depends entirely on your threat model and how much operational detail you want visible.
One thing worth planning for before you go live: Uptime Kuma stores everything in a single SQLite file inside the data volume. That file is small and easy to back up, but it is also a single point of failure. A corrupted database means losing all your monitor configurations, notification settings, and historical uptime data at once. A daily backup of that data folder – whether to an S3 bucket, a network share, or even a simple cron job copying to a second drive – prevents a painful rebuild from memory when something inevitably goes wrong. The monitoring system protecting your services should not itself be unmonitored.
