Administrator Guide

Day-to-day operation of the board. Assumes installation is done — see INSTALL.md.

The board at a glance

• Public board (/) — everyone in your org. Read-only. Shows current outages, scheduled maintenance, and lets visitors subscribe to email alerts.
• Wall dashboard (/wall) — the large-format dashboard for a TV or shared screen. Auto-refreshing tiles. Designed for 1920×1080.
• Admin actions — Log In as a user with the admin or editor role to create and manage incidents.

Incidents

Creating an outage

Add Outage (top bar, when logged in). Required: title, at least one location, outage type. Strongly recommended: severity, impact, user-facing impact text — this is what your subscribers read.

Timestamps default sensibly: started = reported = now. Override them when back-filling an incident that started earlier — the metrics engine uses these to compute time-to-detect.

Keeping it updated

While an incident is active, add an Update whenever the situation changes. Subscribers get an email per update, and the public board shows the full timeline. The reminder scheduler will nudge on-call in the app when a P1 has gone 45 minutes without an update (repeats every 15 minutes). You can mute reminders per-incident (Reminders → Suppress) with a reason — recorded in the audit history.

Resolving

Resolve asks for:

• Resolution notes (required) — what actually fixed it.
• RCA quick-pick — root-cause bucket (hardware / software / network / human process), detection method, contributing factor, preventive action. Four short fields, no essay. They feed the recurring-issues report.

On resolve, the record auto-locks: edits are blocked, preserving the history as it was. An admin can unlock if something truly needs correcting — the unlock is logged.

Scheduled maintenance

Use New Maintenance for planned work. Lifecycle: scheduled → started → completed → closed, with reschedule support at any pre-closed point. Maintenance windows show on the public board ahead of time so users aren't surprised by planned work.

Notifications

• Subscribers get an email when incidents matching their preferences are created or updated. They manage their own subscription through links in every email (verify, unsubscribe).
• Operations DL (OPERATIONS_DL) is copied on outage notifications.
• Google Chat posts incident announcements and resolution notices when GOOGLE_CHAT_WEBHOOK_URL is set.

All notification paths respect per-incident pause — useful when creating a ticket mid-incident that shouldn't broadcast yet.

Users

Admin → Users. Roles:

Users log in with username/password; admins can reset passwords and deactivate accounts. Deactivating keeps the user's history on incidents.

Metrics and reports

The board computes per-incident MTTD / MTTA / MTTR automatically from the timestamps operators enter — no manual timers. The RCA report aggregates root-cause buckets and detection methods over a date range and highlights recurrent locations, which is the fastest way to answer "what keeps breaking?"

License management

Admin → License shows current state (trial days left, licensee, updates entitlement) and is where you paste a purchased key. Activation requires an admin login and verifies the key before saving. If the trial expires, this page is how you get management back without touching the server.

Demo data

If you installed with demo data, purge it once you're ready for production: POST /api/demo/purge (as admin) removes every demo-tagged record and keeps anything you created yourself.

Backups and recovery

• The database (data/db.json) is written atomically; a backup copy is taken at startup and every 24 hours, keeping the newest 10 in data/backups/.
• To restore: stop the app, copy a backup over db.json, start the app.
• For disaster recovery, back up the whole data directory (or the Docker volume) — database, license key, and trial state all live there.

Security notes

• SESSION_SECRET must be unique per installation. Regenerating it logs everyone out; do it if you suspect leakage.
• The public board exposes only status data and subscription endpoints — no user lists, no internal notes, no admin APIs.
• Sessions are httpOnly cookies. Serve the board behind TLS in production.
• License keys are verified locally with an offline signature — the board never phones home, and neither do we.