Uptime Kuma POC — Monitoring & Alerting on Ghaymah Cloud

Goal

Deploy Uptime Kuma as a containerized app on Ghaymah Cloud, prove out HTTP monitoring + Telegram alerting, and expose a public status page — without building a monitoring system from scratch.

Architecture

flowchart TD
    Internet((🌍 Internet))

    subgraph GhaymahCloud ["☁️ Ghaymah Cloud Environment"]
        direction LR
        UK["🚀 Uptime Kuma<br/>(Port: 3001)"]
        DemoWeb["🌐 demo-web-server<br/>(NGINX :80)"]
    end

    Internet --> UK
    Internet --> DemoWeb
    
    UK -- "HTTP Check<br/>(Every 60s)" --> DemoWeb
    UK -. "Alert on Down/Up" .-> Telegram{"📱 Telegram Channel"}
    UK -. "Exposes" .-> PublicPage(["📊 Public Status Page"])
    
    style Internet fill:#f9f9f9,stroke:#333,stroke-width:2px;
    style Telegram fill:#2CA5E0,stroke:#fff,stroke-width:2px,color:#fff;
    style PublicPage fill:#4CAF50,stroke:#fff,stroke-width:2px,color:#fff;
    classDef cloud fill:#f0f8ff,stroke:#4a90e2,stroke-width:2px,stroke-dasharray: 5 5;
    classDef container fill:#ffffff,stroke:#333333,stroke-width:1px,shadow:true;
    class GhaymahCloud cloud;
    class UK,DemoWeb container;

What was deployed

App	Image	Port	Instances	Volume
`uptime-kuma`	`louislam/uptime-kuma:2`	3001	1	`/app/data`
`demo-web-server`	`nginx`	80	1	none

Both run as single-instance Ghaymah Apps. Uptime Kuma is intentionally kept at 1 instance — it stores its data in a local SQLite database, so scaling it out would split monitor history across separate, inconsistent instances.

demo-web-server (plain nginx) was added as a self-owned target to monitor, so the POC watches infrastructure we actually control rather than a third-party test endpoint.

Monitoring setup

Monitor: test app
Type: HTTP(s)
Target: https://demo-web-server-web-9b9b121d.hosted.cumin.dev/
Check interval: every 60 seconds
Retries: 0 (flags Down immediately — good for fast POC testing)
Timeout: 48 seconds

During setup the monitor was pointed first at httpstat.us/200 (found unstable, frequent 502s) and then httpbin.org/status/200 for stability testing, before finally being switched to the team's own nginx instance.

Alerting

Channel: Telegram
Created via @BotFather, bot token and chat ID configured as an Uptime Kuma notification, linked to the test app monitor.
Tested: forced a Down state (pointed the monitor at an endpoint returning HTTP 502) and confirmed a Telegram alert arrived; then restored a healthy endpoint and confirmed the recovery (Up) alert arrived as well.

Public Status Page

URL: https://uptime-kuma-web-3aa83c30.hosted.cumin.dev/status/ghaymah-status
Access: public, no login required
Shows overall status ("All Systems Operational"), the test app monitor grouped under Services, its uptime percentage, and a recent heartbeat history bar.

Data persistence

Uptime Kuma stores its SQLite database and configuration under /app/data inside the container, which is mounted to a persistent Ghaymah volume. Restarting or redeploying the container does not lose monitors, notification settings, or status page configuration.

Export / configuration snapshot

This Uptime Kuma version (2.5.4) does not currently expose a Settings > Backup/Export screen, so uptime-kuma-config-export.json in this folder was assembled by hand from the live dashboard to document every setting used in this POC (monitor config, notification setup, status page config, deployment parameters). Secrets (bot token, chat ID) are intentionally redacted from that file.

How to verify it yourself

Open the status page — no login needed.
To test alerting: edit the test app monitor's URL to point at any endpoint that returns a non-2xx status, save, and wait up to 60 seconds for the next heartbeat. A Down alert should arrive on Telegram. Point it back at a healthy URL to see the Up recovery alert.

Security & Data Resilience

Independent Health Tracking: The Uptime Kuma stack functions as an independent observer. The persistence layer retains the complete outage and metrics history inside an isolated volume.
Failover Alerts Validation: Explicitly validated notification webhooks logic to verify immediate alerting upon HTTP failures and automatic recovery resolution (Up events).
Persistent Storage Configuration: Critical settings (like SQLite DB, configurations) are safely coupled to /app/data volume mount to circumvent ephemeral container cycles.

Next steps (not yet done)

Put Uptime Kuma behind a custom domain / HTTPS via reverse proxy (Ghaymah already terminates HTTPS on its own subdomains, so this is optional for the POC).
Consider Telegram bot token rotation before handing this off, since the token was shared in a chat during setup.