Internal-only incidents

Why you need it

Mark an incident "internal-only" on creation and it stays in your dashboard for triage tracking but never reaches the public status page or subscriber emails. The same tool covers customer-visible AND internal incidents without forcing operators to maintain a second tracker.

• Same UI, single flag. "Mark as internal" toggle on the create-incident modal. The downstream pipeline respects the flag everywhere — no surprise leak.
• Forced-private updates. Subsequent updates on an internal incident are forced IsPublic = false at the service layer. Defence in depth: an operator who forgets the parent is internal can't accidentally publish.
• Excluded from public rollups. Public status page, RSS / Atom feeds, public API — all skip internal incidents.
• Visible in dashboard with badge. Operators see internal incidents in their list with a clear "Internal" tag — no confusion between customer- facing and internal tickets.

Where it pays off

The internal-only flag fits any tracking-only workflow:

• War-room coordination. Major incident in progress, ops is investigating — open an internal incident to coordinate before the public one goes up.
• PR / legal escalation. Issue that might need disclosure but you're working through legal first — internal until the call is made.
• Capacity / cost spikes. Not customer-visible, but worth tracking with the same timeline structure as a real incident.
• Internal post-mortem only. Some incidents you write up internally but never publish.

Related

• Manual incidents
• Post-mortems
• Anomaly-driven proposals