Self-Hosting·6 min read·

Self-Hosting Uptime Kuma for Status Pages

Monitor your services and publish a public status page with Uptime Kuma, Telegram and webhook alerts, health checks, and a single Docker container.

NB

Netbay Infrastructure Team

Netbay Engineering

On this page

Great for your own sanity: a monitor that checks your services and tells you the moment one is down. Uptime Kuma is a beautiful, self-hosted uptime monitor that runs HTTP, TCP, DNS, and ping checks, then pushes alerts to Telegram, email, Slack, or a webhook. The same install can power a public status page your users actually trust.

The quiet value of a monitor is that it removes the guesswork. Instead of discovering a server went down at 2 a.m. when a customer complains, you get a push notification the moment a check fails, with the time and the type of failure recorded. Over time that history becomes your evidence base for deciding what to fix first.

Uptime Kuma is a single Node process with a built-in SQLite database, so deployment is about as simple as self-hosting gets. This guide covers setup, realistic monitor config, and turning your widget into a presentable status page.

Uptime Kuma monitor fan-out your services http/tcp/dns checks Uptime Kuma node + sqlite alert channels telegram/webhook public status page green/red history retries + threshold reduce false alarms

The Compose File

There is one service, one volume, and one port. Deliberately minimal:

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

Because it stores everything in SQLite, backing up is copying one directory. Keep the port bound to localhost and let your reverse proxy serve it over TLS.

Adding Realistic Monitors

Different checks model different failure modes. A good first set combines reachability with content correctness:

text
- HTTP(s) check on your site root, interval 60s
- TCP check on your SSH port, interval 300s
- Ping check to your main server, interval 60s
- DNS lookup for your domain, interval 300s
- Keyword check asserting a marker string appears in the body

For HTTP checks, set a retry count of 2-3 so a single slow request does not page you. Threshold logic means Kuma only flips to DOWN after the retries consume, which cuts false positives dramatically.

Putting the monitor on the same VPS as the services it watches has a hidden weakness: if the whole box goes down, so does the monitor and you learn nothing. The pragmatic fix is to run a second, tiny Kuma instance or a cheap external synthetic check on a different host for your most critical site. That gives you a view from outside your own network, which is the only honest way to observe availability from a user's perspective.

Alerts That Reach You

From the Notification menu, configure a Telegram bot:

text
Bot Token: 123456:ABC...   (from @BotFather)
Chat ID:   -1001234567890  (your channel/group)
Message Template: {{NAME}} is {{STATUS}}

You can attach multiple notification channels to one monitor. For pages on call-parity, a generic webhook on every status change works well:

bash
curl -X POST https://hooks.example.com/team   -H "Content-Type: application/json"   -d '{"text":"Monitor {{NAME}} is {{STATUS}} at {{time}}"}'

Design alerts around what you can actually act on. A pile of every-micro-check-flicker notifications teaches you to ignore them, so prefer fewer, higher-signal alerts: group related services into one monitor or alert only on the production host rather than each container. When something real goes down, you want the notification to be unmistakable, which means reserving alerts for conditions that actually require a human today.

Building the Public Status Page

Uptime Kuma hosts an optional status page per group of monitors. Enable it, pick the monitors you want public, and optionally use a custom domain. Visitors see an honest green/red history without needing an account.

Set incident announcements manually when you know maintenance is coming, which is more credible than silence during an outage window.

A public status page builds trust precisely because it is boring. Update it genuinely after incidents, list the affected services honestly, and keep the history visible rather than hiding failures. Teams that abuse the status page as performance theater lose credibility fast; teams that report incidents accurately earn it. Since Kuma tracks the same data you alert on, keeping the public page truthful costs nothing extra.

Takeaway

Uptime Kuma turns any VPS into an early-warning system for your stack and a transparent status page for your users, all in one small service.

Run it on a 1 GB Ubuntu netbay instance and add monitors as you deploy more apps — available in under 60 seconds at netbayhosts.in.

Keep reading

Follow along on a real VPS

Deploy Linux in under 60 seconds

These guides are written against Ubuntu, Debian, and RHEL-family images — the same ones on NetBay.

Deploy an instance