الملفات
Ghayamah-Uptime/README.md
2026-09-17 00:36:16 +03:00

4.4 KiB

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

                         Internet
                            |
                            v
                  +-------------------+
                  |   Ghaymah Cloud   |
                  +-------------------+
                       |          |
                       v          v
            +------------------+   +------------------+
            |  Uptime Kuma     |   |  demo-web-server |
            |  (container)     |-->|  (nginx)          |
            |  port 3001       |   |  port 80          |
            +------------------+   +------------------+
                 |         |
          HTTP check     Alert on
          every 60s       Down/Up
                 |         |
                 v         v
        Public Status   Telegram
             Page

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

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

  1. Open the status page — no login needed.
  2. 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.

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.