Jared: only for users of matrix.lotusguild.org; tie into Uptime Kuma at https://isitup.lotusguild.org/status/public tracking the homeserver and its sub-services. "Entire sprint, lots of planning, cannot get it wrong."
Facts to design around
Matrix has no scheduled-maintenance signal. Two standard-ish carriers exist: Server Notices (m.server_notice rooms, Synapse admin API — already rendered by Lotus) for the human-readable message, and nothing at all for a machine-readable countdown.
Uptime Kuma exposes a public JSON for a status page: GET /api/status-page/<slug> (monitor groups + maintenance windows with start/end/title/description) and GET /api/status-page/heartbeat/<slug> (current up/down per monitor). Scheduled maintenance is a first-class Kuma feature (Maintenance → schedule → attach to the status page). That gives us the countdown without inventing a Matrix event.
Proposed shape (to be planned, not built yet)
config.json: statusPages: { "matrix.lotusguild.org": "https://isitup.lotusguild.org/api/status-page/public" } — keyed by homeserver, so nothing is hardcoded and other homeservers simply have no banner.
Client polls the JSON (every 5 min, backoff on error, only when the tab is visible). Active/upcoming maintenance → a slim top strip: "Scheduled maintenance: Matrix restarts in 42 min (22:00–22:15)". Any core monitor down (Synapse / LiveKit / lk-jwt / media) → "Voice calls are currently down — we know" strip, so people stop DMing you.
Dismiss per maintenance id; never blocks the UI; degrades to nothing if Kuma is unreachable (Kuma being down must not look like Matrix being down).
Security/privacy: read-only public JSON, no auth, no cookies; CSP connect-src needs the isitup origin added (docker-nginx.conf + prod nginx). The client sends nothing.
Which monitors count as "core" is a Kuma group name (e.g. group "Matrix core") so you control it from Kuma, not from code.
Open questions for Jared (before any code)
Which Kuma monitors/groups map to "Matrix is down" vs "just degraded"?
Banner for upcoming maintenance: how far ahead (24 h? 1 h?)
Should the desktop app also fire an OS notification 10 min before a window?
Do you also want to keep sending a Server Notice for the message body, or let the Kuna description be the message?
Jared: only for users of `matrix.lotusguild.org`; tie into Uptime Kuma at https://isitup.lotusguild.org/status/public tracking the homeserver and its sub-services. "Entire sprint, lots of planning, cannot get it wrong."
### Facts to design around
- Matrix has no scheduled-maintenance signal. Two standard-ish carriers exist: **Server Notices** (`m.server_notice` rooms, Synapse admin API — already rendered by Lotus) for the human-readable message, and nothing at all for a machine-readable countdown.
- Uptime Kuma exposes a **public JSON** for a status page: `GET /api/status-page/<slug>` (monitor groups + *maintenance* windows with `start`/`end`/`title`/`description`) and `GET /api/status-page/heartbeat/<slug>` (current up/down per monitor). Scheduled maintenance is a first-class Kuma feature (Maintenance → schedule → attach to the status page). That gives us the countdown **without inventing a Matrix event**.
### Proposed shape (to be planned, not built yet)
- `config.json`: `statusPages: { "matrix.lotusguild.org": "https://isitup.lotusguild.org/api/status-page/public" }` — keyed by homeserver, so nothing is hardcoded and other homeservers simply have no banner.
- Client polls the JSON (every 5 min, backoff on error, only when the tab is visible). Active/upcoming **maintenance** → a slim top strip: "Scheduled maintenance: Matrix restarts in 42 min (22:00–22:15)". Any core monitor **down** (Synapse / LiveKit / lk-jwt / media) → "Voice calls are currently down — we know" strip, so people stop DMing you.
- Dismiss per maintenance id; never blocks the UI; degrades to nothing if Kuma is unreachable (Kuma being down must not look like Matrix being down).
- Security/privacy: read-only public JSON, no auth, no cookies; CSP `connect-src` needs the isitup origin added (docker-nginx.conf + prod nginx). The client sends nothing.
- Which monitors count as "core" is a Kuma **group** name (e.g. group "Matrix core") so you control it from Kuma, not from code.
### Open questions for Jared (before any code)
1. Which Kuma monitors/groups map to "Matrix is down" vs "just degraded"?
2. Banner for *upcoming* maintenance: how far ahead (24 h? 1 h?)
3. Should the desktop app also fire an OS notification 10 min before a window?
4. Do you also want to keep sending a Server Notice for the message body, or let the Kuna description be the message?
jared
added this to the Features 2026-Q4 milestone 2026-09-17 15:43:35 -04:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Jared: only for users of
matrix.lotusguild.org; tie into Uptime Kuma at https://isitup.lotusguild.org/status/public tracking the homeserver and its sub-services. "Entire sprint, lots of planning, cannot get it wrong."Facts to design around
m.server_noticerooms, Synapse admin API — already rendered by Lotus) for the human-readable message, and nothing at all for a machine-readable countdown.GET /api/status-page/<slug>(monitor groups + maintenance windows withstart/end/title/description) andGET /api/status-page/heartbeat/<slug>(current up/down per monitor). Scheduled maintenance is a first-class Kuma feature (Maintenance → schedule → attach to the status page). That gives us the countdown without inventing a Matrix event.Proposed shape (to be planned, not built yet)
config.json:statusPages: { "matrix.lotusguild.org": "https://isitup.lotusguild.org/api/status-page/public" }— keyed by homeserver, so nothing is hardcoded and other homeservers simply have no banner.connect-srcneeds the isitup origin added (docker-nginx.conf + prod nginx). The client sends nothing.Open questions for Jared (before any code)