Concepts Incidents

Incidents

An Incident is a manually declared service disruption with a tracked investigation state. It's the mechanism for communicating "something is wrong" to your users on the public status page — distinct from the automatic UP/DOWN status computed from Checks, and distinct from an Alert, which is the internal record of a threshold rule firing.

Key properties

Field	Type	Description
Title	string	Required, describes the incident
StartDateTime	long (unix seconds)	When the incident started
EndDateTime	long?	When resolved. Null while active
Status	IncidentStatus	Current investigation state — see below
Source	string?	Origin: MANUAL, WEBHOOK, or ALERT
AcknowledgedAt / AcknowledgedBy	long?, string?	Set when a team member acknowledges the incident
Visibility	IncidentVisibility	Private or Public — see below
CurrentImpact	ServiceStatus	Denormalized worst-case impact, mirrors the latest impact change

Source: Incident.cs, IncidentStatus.cs, IncidentVisibility.cs

Status lifecycle

Investigating → Identified → Monitoring → Resolved

Status	Meaning
Investigating	Default starting state — the team is aware and looking into it
Identified	Root cause has been found
Monitoring	A fix has been applied; watching to confirm it holds
Resolved	The incident is over — a final state
Merged	A special final state (like Resolved) reached when this incident is absorbed into another one via correlation — its timeline and visibility now live on the target incident

Each transition is logged as a timestamped comment/timeline event, forming an audit trail. IsResolved is true for both Resolved and Merged — no further updates, acknowledgments, or impact changes apply once an incident reaches either state.

Privacy — private by default

Every incident starts as Private (IncidentVisibility.Private). It exists in the admin panel, is fully manageable, but is not shown on the public status page until someone explicitly sets it to Public. There is no auto-publish behavior — publishing an incident is always a deliberate action.

⚠️ Note: If you create an incident intending users to see it, remember to explicitly publish it. Creating an incident alone does not make it visible.

Affected services and impact

An incident can target one or more Services, or be marked global (affecting all services). Each affected service association carries its own impact level (DOWN, DEGRADED, etc., tracked via IncidentImpactChange) — so a single incident can, for example, mark the API as DOWN while only degrading the web app.

CurrentImpact on the Incident itself is the denormalized worst-case impact across all its impact changes, kept in sync automatically whenever a new impact change is recorded.

How alerts reach an incident

Incidents do not automatically ingest alerts. An Alert is linked to an incident (creating a new one, or attaching to an existing one) only through an explicit action in the Alerts panel — see Concepts-Alerts for the full flow and the POST /api/v1/alerts/{id}/incident endpoint.

Where to configure

Admin panel → Incidents

Create incidents manually, update their status, manage affected services/impact, and toggle public visibility from there.

Tips

• Keep an incident Private while you're still confirming scope — publish once you're confident in the message you want users to see.
• Use Identified and Monitoring states deliberately; skipping straight from Investigating to Resolved gives users less confidence that the situation was actually understood.
• When multiple alerts represent the same underlying outage, link them all to the same incident from the Alerts panel rather than creating duplicates.

Related

• Alerts — how alerts get manually linked to an incident
• Services — services an incident can affect
• Maintenances — planned disruptions, as opposed to unplanned incidents