> ## Documentation Index
> Fetch the complete documentation index at: https://docs.use.observer/llms.txt
> Use this file to discover all available pages before exploring further.

# 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 **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).

> [!NOTE]
>
> **API equivalent**
>
> Every step above maps to a `/api/v1/incidents/*` endpoint. The
> [API reference](https://docs.use.observer/api/overview.md) documents the full surface, including
> `POST /incidents/{id}/publish`, `POST /incidents/{id}/messages`, and
> `POST /incidents/{id}/resolve`.

## Related

* [Incident lifecycle reference](https://docs.use.observer/docs/reference/incident-lifecycle.md)
* [Customer-scoped incidents](https://docs.use.observer/docs/concepts/customer-scopes.md)
* [Webhook payload reference](https://docs.use.observer/docs/reference/webhook-payloads.md)


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.