Public Status Page

Public Status Page

The sanitized public page — public names, up/down, uptime and last-hour tick bars. No IPs, ports, or internal detail.

Boltarr can feed a separate, public status page — showing your users what's up — without exposing Boltarr itself (which holds your network map and SSH keys).

Boltarr only ever pushes a sanitized summary — public name, up/down, uptime, ticks — never IPs, ports, or internal detail — one-way, over your LAN, to a small separate status app.

Architecture

Boltarr (internal, LAN)  ──push (Bearer token)──►  Status app (public-facing)  ──►  visitors

The status app is a tiny container in the repo under statuspage/. Run it on a separate host from Boltarr.

Security: keep Boltarr off the box that hosts the public page. When you eventually expose the status app to the internet, block its /push endpoint at your reverse proxy (Boltarr's LAN push bypasses the proxy and keeps working) so nobody can POST fake statuses.

Set it up

1. Deploy the status app (on its own host): copy .env.example → .env, set a STATUS_TOKEN, docker compose up -d. It serves a read-only page on its port (default 12102).

2. Mark things public:

• Services — a service's detail panel → tick Public status page, optionally set a Public name. Only services that are both monitored and public appear.
• Hosts — a host's Edit dialog → tick Show on public status page + a public name.

3. Configure the push in Settings → 🌐 Public status page: Enabled, the status app URL (e.g. http://status-host:12102), and the shared Token (same value as the app's .env). Push now to verify.

Boltarr pushes on any status change plus a heartbeat at least every ~60s — so the page stays fresh even if you lengthen the probe interval; only detection slows, not the page.

The page

Up to three sections, each shown only if it has something public:

• Services — your monitored, public services.
• Hosts — public hosts (server, NAS, etc.).
• Networking — public hosts whose device type is router / gateway / switch / unmanaged-switch / firewall / AP.

Each entry shows an up/down dot, an uptime %, and a tick bar — both the window and the bar period are configurable (see Display below). A top banner reads "All systems operational" or "Some systems are down". Below the sections, a Past incidents timeline lists each outage with when it went down, when it recovered, and how long (e.g. down 02:14 → back 03:26 · 1h 12m).

Router/AP/switch showing under "Hosts" instead of "Networking"? Set the host's device type correctly (Edit Host), then push again. See Troubleshooting.

Admin panel

The admin panel — section gating, branding, display windows, announcements, and the maintenance controls, all managed from the page itself.

The status page has its own admin panel — log in from the page itself (set STATUS_ADMIN_PASSWORD in the status app's .env). It's cookie-session + CSRF protected and rate-limits logins, so it's safe to expose. Logging in reveals a settings panel:

• Visibility (gating) — mark each section (Services / Hosts / Networking) Public or Private. A private section is still received but shown only to a logged-in admin — so you can check private things from anywhere by logging in, while the public sees only what you choose. Gating is per section, not per item.

• Display — pick the uptime % window and the history bar period independently, each one of 1 hour / 24 hours / 7 days / 30 days. The 1-hour bar shows one tick per probe (per-minute at the default interval).

• Branding — set the page's name, tagline, footer, logo, and the full colour palette (accent, background, surface, up/down/maintenance/unknown, optional gradient stripe). A legend explains the dot colours. Everything is stored on the status app; the repo ships neutral defaults.

• Announcements — post a banner (info / maintenance / critical) with an optional start/end time. Shows at the top of the page.

• Maintenance calendar — schedule planned, announced maintenance: one-off or recurring (daily / weekly / monthly-by-date / monthly-Nth-weekday) with a start/end time. Visitors see an upcoming list, a month calendar, and an "in progress" banner while a window is live.

• Automated maintenance — recurring expected downtime you don't want to announce (e.g. a nightly backup). Choose the services/hosts it covers and the days + time window. While a covered item dips inside its window, its incident, tick square, and live dot turn amber "Scheduled maintenance" instead of red — the downtime still counts toward uptime; only the cause is relabelled. If it runs past the window, the overrun stays red (so a genuinely long night still stands out). Never appears on the public calendar.

• Past incidents — the timeline under the sections. Clear past incidents hides everything resolved up to now (an ongoing incident stays; new ones still appear). Boltarr keeps its own 31-day history — this only clears the page's list.

• Timezone — the status page's own timezone, driving the calendar and maintenance windows.

Automated maintenance in action. Define a recurring window and tick the services it covers (below). While a covered service dips inside that window, its incident, tick and dot render amber "Scheduled maintenance" on the public page — while a genuine outage in the same view stays a normal incident.