How to Deploy Uptime Kuma Status Monitoring

Uptime Kuma is the self-hosted answer to services like Pingdom or UptimeRobot — a clean, real-time uptime monitor with notifications and public status pages. It's a joy to use and famously easy to run. The one wrinkle for cloud deployment is that it's a *stateful* application: all your monitors, history, and settings live in a local database. This guide gets it running durably.

Understanding Uptime Kuma's storage

Uptime Kuma stores everything in a database under /app/data inside the container — historically SQLite, with optional external database support in newer versions. The critical insight: if /app/data isn't persistent, you lose every monitor and all history on redeploy. Everything else about deployment is trivial; persistence is the whole game.

You have two paths:

Step 1: Deploy the container

Uptime Kuma ships an official Docker image and runs on port 3001. On PandaStack:

1. 1Create a container app using louislam/uptime-kuma:1 (pin the major version).
2. 2Bind the service to port 3001 (or map to the injected port).
3. 3Attach a persistent volume mounted at /app/data so the database survives restarts.
4. 4Add a custom domain — automatic SSL gives your status page HTTPS for free.

The first time you load the UI, you'll create an admin account. That account lives in the data directory, so it persists as long as the volume does.

Step 2: Make storage durable

For a single instance, the persistent volume is enough. Mount it explicitly:

volumes:
  - mount: /app/data
    size: 1Gi

If you're on a platform tier that emphasizes statelessness, prefer the external database option in recent Uptime Kuma releases, which lets the durable state live in a managed PostgreSQL/MariaDB instance instead of on a local volume. Check your version's docs for the supported external DB drivers.

Step 3: Configure your first monitors

Uptime Kuma supports a rich set of monitor types:

• HTTP(s) — the workhorse; checks status codes, response time, and keyword presence.
• TCP Port — for databases, message brokers, custom services.
• Ping (ICMP) — basic reachability.
• DNS — record resolution checks.
• Push — for monitoring cron jobs and background workers (the job pings Kuma; Kuma alerts if the ping stops).

The push monitor is especially useful for verifying that scheduled tasks actually ran — point your cronjob at the push URL and you'll be alerted if it silently stops firing.

Step 4: Notifications

Uptime Kuma supports 90+ notification channels — Slack, Discord, Telegram, email (SMTP), PagerDuty, generic webhooks, and more. Configure them under Settings → Notifications, then attach a notification to each monitor. A few practical tips:

• Set retries before alerting (e.g., 3) so a single blip doesn't page you.
• Set a sensible heartbeat interval — 60s is fine for most services; tighter intervals add load.
• Use maintenance windows to silence alerts during planned work.

Step 5: Public status page

One of Uptime Kuma's best features is the built-in status page. Create one, add your monitors, and publish it on a subdomain like status.yourdomain.com. With automatic SSL and a custom domain, you have a professional status page in minutes — no separate service required.

Resource notes

Uptime Kuma is lightweight. It runs comfortably on a small compute tier — even the smallest tiers handle dozens of monitors. The main resource consideration is history retention: long retention with many tight-interval monitors grows the database. Set a retention period under Settings that matches your needs.

Honest caveats

Uptime Kuma is a single-node application. It doesn't cluster, and if you scale it to multiple replicas you'll get duplicate checks and split state. Run exactly one instance. Also, because it monitors *from* wherever it's deployed, a single deployment only tells you reachability from one region — for true multi-region uptime checks you'd run multiple instances or use a distributed monitoring service. And the obvious one: don't host your status page on the same infrastructure you're monitoring, or an outage takes both down. Deploy your status page on independent infrastructure.

Wrapping up

Uptime Kuma proves that self-hosted monitoring doesn't have to be painful. Deploy the container, give /app/data durable storage (or use an external database), wire up notifications, and publish a status page. That's a complete monitoring solution you fully own.

PandaStack supports persistent volumes and custom domains with automatic SSL, so a durable Uptime Kuma plus a public status page fits comfortably in the free tier. Deploy yours at https://dashboard.pandastack.io.

References

• Uptime Kuma repository: https://github.com/louislam/uptime-kuma
• Uptime Kuma Docker image: https://hub.docker.com/r/louislam/uptime-kuma
• Uptime Kuma wiki (installation): https://github.com/louislam/uptime-kuma/wiki/Installation
• Uptime Kuma notification list: https://github.com/louislam/uptime-kuma/wiki/Notification-Methods
• Monitoring cron jobs with push monitors: https://github.com/louislam/uptime-kuma/wiki