The ask: when something's wrong — or about to be planned-wrong — every PURE user sees it, knows the impact, knows when it's fixed, without anyone fielding 500 "is it down?" calls. The structure below follows what Statuspage-class and large-platform teams (GitHub/AWS-style health comms) standardized: one source of truth, many surfaces, lifecycle updates, advance maintenance notices, and auto-expiry — sized for a 50K-user MLS.
WHAT USERS SEE — the four banner kinds (live mocks)
SEV-1 · OUTAGESearch is down — we're on it.Identified 2:14 PM · next update 2:45 PM · INC-7 · details at status—
SEV-2 · DEGRADEDPhoto uploads are slow.Workaround: save drafts; fix ETA 5:00 PM today✕
MAINTENANCEScheduled maintenance Sunday 2–4 AM CT.MLS feeds pause; everything else stays up · starts in 2d 14h (live countdown)✕
NOTICENew: Pure Appraiser is live in the Store.Also usable for announcements, fee deadlines, board votes✕
- SEV-1 is NOT dismissible and shows everywhere; everything else dismisses per user (remembered).
- Maintenance banners appear automatically at T-72h, T-24h, T-1h, switch to "in progress" during the window, auto-resolve after — nobody has to remember to take them down.
- Every banner deep-links to the status page (B-T77) for the full timeline.
HOW IT WORKS — one row, every surface
| PIECE | WHAT |
|---|---|
pure_banners table | kind (outage/degraded/maintenance/notice) · severity · title · message · impact · eta_fix · window_start/end · audience (all / hat / org) · status (scheduled/live/resolved) · created_by · updates[] (the lifecycle timeline) |
pure-banner.js drop-in | ONE script tag on every surface (shell, lane pages, fable, status page). Polls the table, renders the right banner for the viewer's hat, handles dismiss-memory, countdowns, auto-expire. ~3KB. |
| Composer | In the Command Center + the status page: pick kind → fill title/impact/ETA → preview → publish. Maintenance kind asks for the window and schedules the T-72/24/1 notices automatically. Templates included ("investigating", "identified", "monitoring", "resolved") so updates take 10 seconds. |
| Push beyond the product | Publishing a SEV-1 or maintenance row also: posts to team_messages (staff), Lane Mail (lanes act), and — Phase 2 — email/SMS to subscribed members via the UptimeRobot contacts now and a proper subscriber list later. Members can subscribe per component (MLS feeds, billing, search) exactly like big-platform status subscriptions. |
| Discipline | Only super admin + named staff can publish SEV banners (approval column, same pattern as APR rows); notices open to staff. Every publish/update/resolve writes audit rows. Post-incident: resolved banners require a one-line "what happened" that lands on the status page history. |
ROLLOUT
| PHASE | SHIPS | NEEDS |
|---|---|---|
| 1 · Now | pure_banners table + pure-banner.js on every lane surface + composer in Command Center + maintenance scheduling/auto-expiry | approval only |
| 2 · Reach | Shell + fable integration at the Combine (Lane A's files — B-M claim or their pickup) · email/SMS push to member subscribers · status-page subscription form | Lane A coord · APR-8b |
| 3 · Scale | Realtime (no polling) · per-component subscriptions · auto-banner from monitors (UptimeRobot down = draft SEV-1 waiting for one-tap confirm) | ND-6 key · MCP |
FOR YOUR APPROVAL — APR-8
a) Approve the banner system + composer (Phase 1 builds now, on every lane surface).
b) Member push (email/SMS) for SEV-1 + maintenance — confirm members should receive these off-platform.
c) Who besides you can publish SEV banners? (Suggest: Shattique for infrastructure, Ana for MLS ops.)