Uptime Kuma on a VPS: Self-Hosted Uptime Monitoring, Alerts, and a Status Page for Under 100 MB of RAM

External uptime monitors charge per check and store your site’s availability data on someone else’s server. Uptime Kuma is the self-hosted alternative: it runs on your own VPS, supports unlimited monitors, pushes alerts to Telegram, Discord, email, or ntfy, and ships with a public status page. Its entire footprint is under 100 MB of RAM, which means it coexists happily with a web server on the smallest VPS plan. Here is how to set it up properly, wire the notifications, and avoid alert fatigue.

What you get, and what it costs

Resource	Footprint
RAM	60–90 MB (Docker container)
Disk	~150–250 MB (app + SQLite database)
CPU	Negligible; one check every 60 s per monitor
Monitors	Unlimited (practical limit: thousands)

Compare that with per-check pricing from hosted services: the monitoring stack costs you a slice of a VPS you are probably already renting, and the data stays yours.

Install with Docker

The official container is the smoothest path. Bind it to localhost only — you will put TLS in front of it in the next step, and the admin UI should never be reachable over plain HTTP:

mkdir -p /opt/uptime-kuma/data
docker run -d --name uptime-kuma \
  -p 127.0.0.1:3001:3001 \
  -v /opt/uptime-kuma/data:/app/data \
  --restart=always \
  louislam/uptime-kuma:1

Prefer not to run Docker on your production VPS? Uptime Kuma also runs directly with Node.js (npm install then node server/server.js), or inside a separate container on a dedicated monitoring box.

Put it behind HTTPS

Front the localhost port with a reverse proxy that terminates TLS, exactly like you would for any internal service. A Caddy or nginx vhost for status.example.com with automatic certificates takes five minutes and keeps the admin panel off the wire. Once that is up, create your admin account and set a strong password — Uptime Kuma holds credentials for your notification channels, so treat it like a production service.

Monitor types that matter

• HTTP(s) with keyword — checks a URL and optionally asserts a string in the response; catches “200 but broken” failures, not just “down”.
• TCP port check — verifies that a port accepts connections; useful for SSH, databases, and mail servers.
• Ping — coarse reachability for hosts without an agent.
• DNS — confirms your nameservers answer with the expected record.
• Push (heartbeat) — your server or a cron job pings the endpoint on schedule; silence means failure. Ideal for jobs behind NAT, like a nightly backup.

Group monitors per service (web, database, backups) so a single incident page tells the whole story at a glance.

Wire notifications without alert fatigue

Uptime Kuma supports Telegram, Discord, email, ntfy, Slack, and dozens more out of the box. The settings that keep alerts useful: check every 60 s, retry twice before declaring an incident, resend the notification at most every 5 minutes, and cap it at a few messages per incident. Use the maintenance mode during deploys so scheduled restarts do not page you at midnight.

An example monitor set for a typical VPS

To make it concrete, here is the monitor set a typical single-VPS web setup should start with:

• HTTP keyword on https://your-site/, asserting a string from your homepage — catches both downtime and broken responses.
• TCP port 22 — confirms SSH stays reachable for recovery.
• TCP port 443 — separate from the HTTP check, so a closed port and a broken app layer are distinguishable.
• DNS on your domain — verifies resolution still points where it should.
• Push monitor pinged by the nightly backup cron — a missed ping means the backup failed silently.

That is five monitors covering the failure modes that actually take a small VPS down, with the alert load of a single incident page.

Build the status page

The built-in status page gives you a public, embeddable view with per-service groups, uptime percentages, and incident history — the kind of transparency SaaS teams pay for. Be honest about one limitation: if the status page runs on the same VPS as the service it reports on, both go down together. For small setups that is usually acceptable; for a production service, run a second Uptime Kuma instance on a different provider and point the status page at that one. If you are choosing the second provider, compare providers on our VPS comparison table for a cheap box in a different region.

Keep the monitoring data safe

Everything — monitors, credentials, history — lives in a SQLite database inside the volume. Back up /opt/uptime-kuma/data with your regular backup pipeline, and migrating to a new VPS is as simple as restoring the volume and starting the container. It is a small file, so even daily backups are trivial.

A monitoring box that costs 90 MB of RAM is the cheapest insurance your VPS-hosted applications can buy — and because it is self-hosted, the only person who sees your availability data is you.

If your application runs on managed cloud hosting, a separate monitoring VPS keeps an independent eye on it. And if you are still choosing where to host the application itself, Cloudways’ managed plans take the sysadmin load off while your Uptime Kuma box watches from outside.