update readme

README.md

@@ -39,29 +39,34 @@ flowchart TD
 |--------------------|----------------------------|------|-----------|--------------|
 | `uptime-kuma`      | `louislam/uptime-kuma:2`  | 3001 | 1         | `/app/data`  |
 | `demo-web-server`  | `nginx`                   | 80   | 1         | none         |
+| `status-page`      | `nginx:alpine`            | 8080 | 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.
+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.
 
+`status-page` is a custom GitHub-style status page (HTML/CSS/JS) served
+by nginx. It fetches live data from the Uptime Kuma public API and
+displays service health with heartbeat bars and uptime percentages.
+
 ## 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
+| Monitor | Type | Target | Interval |
+|---------|------|--------|----------|
+| `test app` | HTTP(s) | `https://demo-web-server-web-9b9b121d.hosted.cumin.dev/` | 60s |
+| `test uptime kuma` | HTTP(s) | `https://uptime-kuma-web-3aa83c30.hosted.cumin.dev/` | 60s |
 
-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.
+Both monitors use 0 retries (flags Down immediately) and a 48-second
+timeout. `test uptime kuma` is a self-monitoring check — Uptime Kuma
+watching itself to detect if the monitoring service goes down.
+
+During setup the `test app` monitor was pointed first at `httpstat.us/200`
+(unstable, frequent 502s) and then `httpbin.org/status/200` for stability
+testing, before finally being switched to the self-owned nginx instance.
 
 ## Alerting
 
@@ -75,11 +80,18 @@ nginx instance.
 
 ## Public Status Page
 
+### Built-in (Uptime Kuma)
 - **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.
+- Shows overall status, both monitors grouped under **Services**, uptime
+  percentages, and heartbeat history bars.
+
+### Custom (GitHub-style)
+- **Files:** `status-page/index.html` + `status-page/nginx.conf`
+- **Local:** `http://localhost:8080` (via `docker compose up status-page`)
+- Fetches live data from the Uptime Kuma public API; proxies it through
+  nginx to avoid CORS. Displays 90-heartbeat bars, 24h/30d uptime %,
+  and animated status indicators. Auto-refreshes every 60 seconds.
 
 ## Data persistence
 
@@ -114,7 +126,7 @@ token, chat ID) are intentionally redacted from that file.
 
 ## 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).
-
+- Deploy the custom status page to Ghaymah Cloud via `gy deploy` to
+  give it a public URL.
+- Add monitors for real application services once a backend app is
+  deployed, replacing the current demo targets.