Uptime Kuma: SME uptime page with HTTP, TCP, ping, and Docker checks

What is Uptime Kuma?

Uptime Kuma is a self-hosted uptime-monitoring solution, launched in 2021 by Louis Lam as a response to the proprietary Uptime Robot. As of May 2026 the project has over 60,000 GitHub stars and is arguably the most popular open-source uptime tool. Licence: MIT – fully free, no clauses, no open-core limits.

The concept stays deliberately small: Uptime Kuma probes regularly (interval configurable, default 60 seconds) whether an endpoint responds. If not, an alert goes out – Telegram, Slack, Discord, Gotify, ntfy, email, or 90+ other receivers. The UI shows a list of all monitors with green/red lights plus heatmaps for the last 24 hours, 30 days, and 1 year.

13+ monitor types are supported: HTTP(s) with status-code check, HTTP(s) with keyword match in the response body, TCP port, DNS lookup, push (heartbeat from an external job), ping (ICMP), Docker container, Steam server, gRPC, MQTT, MongoDB, PostgreSQL, MySQL, Redis, Kafka. That covers almost every SME need.

Special feature: status page. A public or token-protected status page is built in the UI – typical for a SaaS platform that wants to inform customers about outages. Free URL slug, custom logo, custom CSS. With that, an SME has a professional "status.firm.ch" page without extra components.

Footprint: one Docker container, SQLite or MariaDB as backend, around 150 MB RAM at idle. Runs comfortably on a 1-vCPU server. Setup: docker run, browser to port 3001, create admin account, done. Realistically productive in 5 to 10 minutes.

Why it matters

Uptime Kuma solves exactly the SME need that is too much for Prometheus and too little for nothing: knowing whether external endpoints (websites, APIs, database ports, mail servers) respond. Prometheus checks that via blackbox-exporter, but it needs a full Grafana stack. Uptime Kuma delivers the same function in a single container with its own UI.

SME suitability (May 2026): arguably the lowest setup investment in the monitoring space. A fiduciary office with a website, a Bexio link, a mail server, and a backup NAS sets up four monitors plus a status page in 30 minutes – no YAML, no PromQL, no Grafana. Alerts go to Telegram, done.

CH DSG fit: Uptime Kuma runs self-hosted in Docker. The data – when does which endpoint respond – stays on your own server. No US component, no data-transfer discussion. For clients under professional secrecy (Art. 321 SCC) this is the clean alternative to commercial cloud services like Uptime Robot or Better Uptime.

Status page as trust element: a public status page (status.firm.ch) shows customers and partners that the company takes monitoring seriously. During an outage, communication becomes more transparent – customers see the disruption themselves and call less often. For SaaS-oriented SMEs this is an important customer-trust tool.

Push heartbeat for cron jobs: a lesser-known feature. A cron job (backup, dunning, newsletter) sends an HTTP heartbeat every X minutes to an Uptime Kuma push monitor. If the cron fails, Uptime Kuma is the first to know after timeout. That lets you monitor "invisible" routines without their own /health endpoint.

How it works

Uptime Kuma is a Node.js application with a built-in web UI (Vue.js). One main process runs probes, writes results to SQLite or MariaDB, and delivers alerts through configured receivers.

docker-compose.yml example:

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

After first start: browser to http://server:3001, create admin account (username + password), done. Behind an nginx reverse proxy with Lets-Encrypt cert, this runs productively at status.firm.ch.

Create monitor: + Add New Monitor, choose type (HTTP, TCP, Push, Docker, etc.), enter URL/host/port, interval (default 60s), retries (default 0), choose notification receivers. Done in 30 seconds.

Notification receivers: Telegram bot with chat_id and token, Slack webhook, Discord webhook, Gotify, ntfy.sh, generic webhook, SMTP, Apprise (bridge service to 80+ further services). Multiple receivers per monitor.

Create status page: Status Pages → + Add New, choose slug (e.g. "public"), assign monitors, choose theme, optional custom domain via nginx subdomain. Public or token-protected. The status page updates automatically, customers need no login.

Docker container monitor: a special type. Instead of probing a port, Uptime Kuma checks directly via Docker socket whether the container is "running" and "healthy" (if a healthcheck is defined). That detects containers that are technically running but not responding – e.g. process crash inside a container.

Push monitor for cron: Uptime Kuma generates a URL like `/api/push/abc123?status=up&msg=ok`. The cron job calls this URL via curl. If no call arrives in X minutes, Uptime Kuma triggers. Very useful for backup jobs, dunning cron, cleanup scripts.

Setup in 5 steps

1. 01Start docker-compose with louislam/uptime-kuma:1, persist the volume, expose port 3001.
2. 02Create admin account, then activate auto-lock on login attempts (Settings -> Auth Rate Limit).
3. 03Create a Telegram bot, obtain chat_id, register in Uptime Kuma as notification channel, send a test notification.
4. 04Create monitors in order: 1) website HTTP, 2) API HTTP keyword, 3) PostgreSQL port, 4) Docker container, 5) push heartbeat for backup cron.
5. 05Create status page, subdomain status.firm.ch via nginx reverse proxy, Lets-Encrypt cert, branding (logo, colours).

When to use Uptime Kuma

Uptime Kuma is the right choice when (a) the setup has fewer than 25 endpoints/containers, (b) a simple reachability status is enough (no drill-down into latency histograms), (c) a public status page is desired, (d) setup time under one hour is required.

Concrete SME cases: a fiduciary website plus Bexio link plus backup NAS plus mail server – four monitors suffice. A law firm with own client platform plus PostgreSQL plus Redis – five to seven monitors. A SaaS vendor with public status.firm.ch page – Uptime Kuma plus nginx subdomain.

Good complement to Prometheus: Uptime Kuma for external reachability (what does the customer see?), Prometheus for internal depth (why is it slow?). At Fairlane both run in parallel – Uptime Kuma for 14 public endpoints with Telegram alerts, Prometheus for 25 container-internal metrics. Uptime Kuma setup: 20 minutes, ongoing maintenance: near zero.

When not to use

Uptime Kuma is the wrong choice when (a) deep application-performance monitoring is needed – latency histograms, P95/P99, per-endpoint error rates – then Prometheus plus Grafana, (b) log analysis is the main need – then Loki, (c) the setup grows past 50+ endpoints and must be multi-tenant – then Zabbix or Datadog.

Pitfalls: using Uptime Kuma as the sole monitoring solution for complex RAG or LLM pipelines – it only sees whether the HTTP endpoint responds, not whether the model hallucinates or latency rises. Setting alerts on a 60-second interval without retries – flapping probes produce false positives. Making a status page public with labels that reveal business internals ("Client CRM v2.5 Prod") – attackers welcome architecture hints.

Anti-patterns: Uptime Kuma plus Uptime Robot plus Pingdom in parallel – three UIs, three alert streams, triple alert fatigue. Push monitor without a cron watchdog – if the cron job itself dies, it cannot send a heartbeat. Plan a systemd timer health-check or container healthcheck on top.

Trade-offs

FAQ

Related topics

Sources

1. Uptime Kuma – GitHub repository · 2026-05
2. Uptime Kuma – Documentation Wiki · 2026-04
3. Apprise – Notification bridge service · 2026-03
4. Self-hosted comparison – Uptime tools 2026 · 2026-04