Skip to main content
Incidents are the customer-facing comm layer that sits on top of metric-driven status. This page walks through filing one end to end: draft, publish, append a follow-up, resolve. Every step has an API equivalent (see the API tab) for IR automation.

​
Prerequisites

  • An organisation with at least one service. If services are not yet defined, create one under Services > New service before starting.
  • Optional: an SLO bound to the service. The Impact section on the incident page only has data when an affected service has at least one SLO.

​
Steps

1

Open the new-incident form

In the console, open Incidents and select New incident. The Type is Incident. The form prompts for severity, title, affected services and pages, affected customers, and a first message.
2

Fill the headline

  • Severity: minor, major, or critical. The badge color on the public page follows this value.
  • Title: one customer-facing sentence (avoid jargon and internal IDs; this is what visitors will see at the top of the timeline).
  • Services: pick at least one. The Impact section reads this list to compute SLO budget used during the incident. Services choose the pages the incident appears on; add more under Show on pages.
  • Affected customers: leave as is for a public incident. Name specific customers to make it a private incident that reaches only them.
  • First message: the Message type (for example Investigating) and the Message customers read first.
3

Decide draft vs publish

The form has two submit buttons:
  • Save as draft: creates the row but does not publish. The incident is editable; nothing renders on the public page or fires to webhook subscribers.
  • Publish and notify subscribers: sets published_at = now(), fires incident.published, and renders the incident on the public page.
For the first incident, choose Save as draft so you can review the form before going customer-facing. The next step publishes.
4

Add a message

Open the incident from the Incidents list. The incident page shows an Impact section (live SLO budget used, refreshed every 30 seconds), the Timeline of messages, and an Add message button.Add a message of type Identified with a brief description. The public page renders messages in chronological order under the incident header.
5

Publish the incident

Select Publish and notify subscribers next to the incident’s Status. The incident now renders on the public page. Webhook subscribers receive incident.published and incident.message_added events.
6

Resolve

When the underlying issue clears, select Resolve incident (or add a final message of type Resolved). Observer marks the incident resolved (resolved_at populated, lifecycle pill flips to resolved, incident.resolved webhook fires).
API equivalentEvery step above maps to a /api/v1/incidents/* endpoint. The API reference documents the full surface, including POST /incidents/{id}/publish, POST /incidents/{id}/messages, and POST /incidents/{id}/resolve.