kOlapsis/maintenant v1.2.11

Status Page personalization

on GitHub

This release reshapes the public status page around two themes: brand personalization and a cleaner, more powerful component model.

Pro users can now dress the public /status page in their own colors, logo, language, announcement banner, footer, and FAQ. On the component side, the legacy single-monitor mapping is replaced by composition modes that let one status component aggregate multiple monitors — either by explicit selection or by matching every monitor of a given type. The never-finished component groups feature is retired in the process.

New features

Status page personalization (Pro)

The Personalization tab in /status-admin lets you brand your public /status page end-to-end:

• Branding — page title, subtitle, logo, favicon, and hero image. Uploads are queued locally and applied atomically when you click Save changes — the live page no longer changes mid-edit.
• Color palette — background, surface, border, text, accent, and four severity colors. Contrast ratios are checked against WCAG AA at save time and surfaced as warnings before they ship.
• Announcement banner — togglable banner at the top of /status with a Markdown message and an optional link.
• Footer — Markdown body plus a list of footer links (drag-and-drop reorder).
• FAQ — drag-and-drop ordered Q/A entries with Markdown answers, rendered as collapsible items on the public page.
• Localization — pick the public page locale (English or French today), the timezone used to format dates, and whether timestamps display as relative ("5 min ago") or absolute ("2026-05-03 21:14").

All Markdown is rendered server-side and sanitized through bluemonday: scripts, iframes, inline event handlers, and inline styles are stripped before content reaches the public page. External links are automatically rewritten with target="_blank" rel="noopener noreferrer".

The public /status payload exposes a single ETag-cached settings document that is invalidated automatically on every change — content updates show up on the next refresh, no waiting for a TTL window.

Status component composition modes

A status component can now represent more than a single monitor:

• Explicit composition — pick the exact set of monitors (containers, endpoints, heartbeats, certificates) that make up the component. The public page shows a per-monitor breakdown when you expand the component.
• Match-all composition — match every monitor of a given type (e.g. "all containers" or "all certificates") without enumerating them. New monitors that match are picked up automatically.

The matched monitors are rolled up into a single component status using the worst-status-wins rule, so a component degrades the moment any underlying monitor degrades.

Fixes

• BrandingSection — file uploads no longer fire on click; they're queued and applied at Save. The previously-stale file input is reset on Clear/Save, and all inputs render correctly under both light and dark themes (they were dark-only before).
• FAQ on public page — entries created in the admin tab now actually appear on /status. The public payload also bumps its version on FAQ, footer-link and asset changes, so the ETag updates immediately and browsers stop serving stale cached content.

Breaking changes

• Component groups removed — the /api/v1/status-admin/groups endpoints, the component_groups table, the Group dropdown in the admin UI, and the related quota field are all gone. Migration 16_drop_component_groups drops the table on upgrade. If you were not using groups (the feature was never finished or documented), this change is transparent.
• /status/api payload shape — the public status API now returns a flat components[] array instead of groups[]. Anything consuming that endpoint (custom dashboards, scrapers) needs to be updated.
• Component schema — monitor_type / monitor_id columns on status_components are replaced by a composition_mode column plus a status_component_monitors join table. Migration 15_status_component_monitors performs the in-place data migration; existing single-monitor components keep working under the new explicit mode.

Database migrations

This release ships three new migrations:

• 15_status_component_monitors — composition modes + join table, in-place migration of existing components
• 16_drop_component_groups — removes the unused component_groups table
• 17_status_personalization — settings, assets, footer links, and FAQ tables for the new personalization feature

Migrations run automatically on container start.

Upgrading from v1.2.10

docker compose pull && docker compose up -d --force-recreate

If you have an external consumer of /status/api, update it to read the new flat components[] shape before upgrading.