Summary
Add the ability to create and display incidents/announcements on status pages. The database table StatusPageIncident already exists in the codebase but there is no API or UI to manage them, nor any display on the status page itself.
Use Case
When services go down or there is an ongoing issue, operators need a way to communicate with end-users directly on the status page. Similarly, planned changes or post-mortem notes should be visible.
Proposed Features
Backend / API
- CRUD endpoints (create, list, update, delete) for
StatusPageIncident tied to a MonitorStatusPage
- Incidents should have:
name (title)
payload with fields like:
status: resolved | investigating | identified | monitoring
message (Markdown body)
startedAt / resolvedAt timestamps
- Link to the specific
MonitorStatusPage (currently the table has no FK to the status page)
Frontend / UI
- Admin panel: a section under Monitor → Status Page → Edit where users can manage incidents (create, update status, resolve)
- Status page display: show active/resolved incidents above the service list, with status badges (e.g., 🟡 Investigating, 🟢 Resolved)
- Optional: email/webhook notifications when a new incident is created
Reference StatusPageIncident Schema (already exists)
StatusPageIncident {
id: String (PK)
createdAt: DateTime
updatedAt: DateTime
name: String(100)
payload: JSON (StatusPageIncidentPayload)
}
Copiar
The schema is defined in src/server/prisma/zod/statuspageincident.ts but currently unused in the API layer.
Why This Matters
Without an incident system, status pages are purely passive — they show uptime but cannot communicate actively with users during outages.
Summary
Add the ability to create and display incidents/announcements on status pages. The database table
StatusPageIncidentalready exists in the codebase but there is no API or UI to manage them, nor any display on the status page itself.Use Case
When services go down or there is an ongoing issue, operators need a way to communicate with end-users directly on the status page. Similarly, planned changes or post-mortem notes should be visible.
Proposed Features
Backend / API
StatusPageIncidenttied to aMonitorStatusPagename(title)payloadwith fields like:status:resolved|investigating|identified|monitoringmessage(Markdown body)startedAt/resolvedAttimestampsMonitorStatusPage(currently the table has no FK to the status page)Frontend / UI
Reference StatusPageIncident Schema (already exists)
StatusPageIncident {
id: String (PK)
createdAt: DateTime
updatedAt: DateTime
name: String(100)
payload: JSON (StatusPageIncidentPayload)
}
Copiar
The schema is defined in
src/server/prisma/zod/statuspageincident.tsbut currently unused in the API layer.Why This Matters
Without an incident system, status pages are purely passive — they show uptime but cannot communicate actively with users during outages.