Skip to main content

Incidents and Maintenance

StatiBeat is built to make status communication easier for your team and clearer for your customers.

Incident administration​

The admin UI for incidents currently includes:

  • create incident
  • create incident from an AI-assisted draft when AI is configured
  • edit incident
  • add update
  • resolve incident
  • reopen a resolved incident when policy allows it
  • draft and publish a Post-Incident Report after resolution
  • revise or unpublish an existing Post-Incident Report
  • delete incident
  • edit component impacts
  • filter ongoing versus resolved incidents

These flows are implemented in application/frontend/src/pages/admin/IncidentManagement.jsx.

For historical imports or cleanup work, the backend also supports admin-only incident backfill routes. Those routes are meant for retrofilling past incidents from another tool or from an internal incident log. They are currently backend-first APIs rather than a dedicated admin UI flow.

During incidents​

Focus on clarity first:

  • identify affected services
  • publish a short initial update quickly
  • keep follow-up messages consistent
  • close with a clear resolution message

Customers do not need every internal detail. They do need confidence that you understand the problem and are actively responding.

Post-Incident Reports​

Resolved incidents can also carry a Post-Incident Report.

That report is separate from the live incident timeline:

  • incident updates explain what changed while the issue was active
  • the Post-Incident Report explains what happened after the fact
  • drafts stay admin-only until an operator publishes them

On public surfaces, only published Post-Incident Reports are shown, and only while the incident remains resolved.

Historical backfill​

Historical backfill is designed for reconstructing the real timeline of a past incident or maintenance window.

  • incident backfill accepts an explicit started_at, optional acknowledged_at, optional resolved_at, and ordered updates with their own timestamps
  • maintenance backfill accepts a scheduled window plus ordered, timestamped updates
  • non-scheduled historical maintenances need at least one status-bearing update so the platform does not invent transition times
  • backfill is silent by default, so it does not replay subscriber notifications, Slack fanout, or live WebSocket announcements

That silence is intentional. A retrofilled event should appear in history and feeds, but it should not surprise subscribers with stale notifications.

Maintenance administration​

The maintenance UI currently supports:

  • creating and editing maintenance windows
  • selecting affected items
  • scheduling date/time ranges
  • adding maintenance updates
  • using preset messages
  • auto-transition messages for maintenance start and completion
  • deleting maintenance windows
  • marking maintenance complete
  • cancelling maintenance windows
  • filtering upcoming, active, and past maintenance work

These flows are implemented in application/frontend/src/pages/admin/MaintenanceManagement.jsx.

Like incidents, maintenances can also be backfilled through admin API routes when you need to reconstruct past work after a migration or import.

During planned maintenance​

Maintenance updates should make timing and impact easy to understand:

  • what is changing
  • when it starts
  • who might be affected
  • when users should expect things to be normal again

Why this matters​

When communication fails, customers often assume the worst. StatiBeat helps you show what is happening visually so trust does not erode faster than the incident itself.