QuickstartFile your first incident

File your first incident

Walk a draft → publish → update → resolve incident through the console.

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 auto-impact panel on the incident detail page only renders when an affected service has at least one SLO.

Steps

Open the new-incident form

In the console, navigate to Updates > Post update. Pick Incident as the type. The form prompts for severity, title, affected services, and customer visibility.

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).
  • Affected services: pick at least one. The auto-impact panel reads this list to compute SLO burn during the incident.
  • Visibility: leave empty for a public incident. Pick specific customers to scope the incident to those tenants only.

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 now: 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.

Append the first message

Open the incident from the Updates list. The detail page shows an Auto-impact panel (live SLO burn, polled every 30 seconds), the message timeline, and a New message popover.

Add a message of type Investigating with a brief description. The public page renders messages in chronological order under the incident header.

Publish the incident

Use the right-side rail action to publish. The incident now renders on the public page. Webhook subscribers receive incident.published and incident.message_added events.

Resolve

When the underlying issue clears, append a final message of type Resolved. Observer auto-marks the parent incident resolved (resolved_at populated, lifecycle pill flips to resolved, incident.resolved webhook fires).

API equivalent

Every 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.

Was this page helpful?