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

# Create an Incident

> Open an incident from the scaling.cloud dashboard, page the on-call responder, and move it through its lifecycle to resolution.

This guide walks you through creating an incident in the dashboard, paging the on-call responder, and moving it through its lifecycle to resolution.

<Tip>
  Driving incidents from a script or pipeline instead? See the [Incidents API](/developers/incidents-api) guide.
</Tip>

<Steps>
  <Step title="Open the create form">
    Go to **Incidents** in the dashboard (`/incidents`) and click **Create Incident** in the top right. This opens the new-incident form at `/incidents/new`.
  </Step>

  <Step title="Fill in the incident details">
    Complete the form:

    | Field                   | Required | Notes                                                                                                                                                             |
    | ----------------------- | -------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------- |
    | **Title**               | Yes      | A short summary, e.g. *Database connection pool exhausted*.                                                                                                       |
    | **Description**         | No       | Additional context about the incident.                                                                                                                            |
    | **Severity**            | Yes      | One of **Critical**, **High**, **Medium**, or **Low**. Defaults to **Medium**.                                                                                    |
    | **Affected components** | No       | Tag the components or services this incident is affecting. You can change this later.                                                                             |
    | **On-call lead**        | No       | Pick an on-call schedule. The current on-call responder is assigned as the incident lead, and any escalation policy targeting that schedule kicks in immediately. |

    <Note>
      Choosing an **On-call lead** schedule is how paging starts from the dashboard — the current responder on that schedule is paged and becomes the incident lead. If you leave it blank, the incident is created without paging anyone; you can assign a lead later from the incident page.
    </Note>

    Use the severity levels consistently across your team:

    | Severity     | When to use                                      |
    | ------------ | ------------------------------------------------ |
    | **Critical** | Complete outage or data loss affecting all users |
    | **High**     | Major degradation affecting most users           |
    | **Medium**   | Partial degradation or workaround available      |
    | **Low**      | Minor issue with minimal user impact             |
  </Step>

  <Step title="Create the incident">
    Click **Create Incident**. scaling.cloud opens the new incident's detail page. Every incident starts in **investigating** status. If you selected an on-call lead, the responder is paged right away — see [Acknowledge and hand off](/guides/acknowledge-and-handoff) for what they do next.
  </Step>

  <Step title="Move the incident through its lifecycle">
    On the incident detail page, use the **Post update** card to record progress. Each update is internal by default; tick the **Also transition to …** checkbox — it names the next status in the sequence — to advance the incident as you post.

    Status moves one way through the sequence:

    `investigating` → `identified` → `monitoring` → `resolved`

    Post an update and transition to **identified** once you've found the root cause, then to **monitoring** when a fix is deployed and you're watching for confirmation.

    <Tip>
      To publish a customer-visible message on your [status page](/concepts/status-pages) as you go, switch the update's visibility to **public** before posting. See [Publish a Status Page](/guides/publish-status-page).
    </Tip>
  </Step>

  <Step title="Resolve the incident">
    When the incident is fully mitigated and confirmed stable, post a final update and tick **Also transition to resolved**. When you transition to resolved, the body of that update becomes the **resolution note** on the timeline.

    <Note>
      **Resolved is terminal.** Once an incident is resolved, no further status changes or updates can be posted on it. If you want a post-incident write-up to appear on your status page, publish it as a **public** update *before* resolving.
    </Note>
  </Step>
</Steps>

## Next steps

<CardGroup cols={2}>
  <Card title="Acknowledge and hand off" href="/guides/acknowledge-and-handoff" icon="bell">
    What the paged responder does when the alert comes in.
  </Card>

  <Card title="Configure Escalation" href="/guides/configure-escalation-policy" icon="layer-group">
    Set up the chain of responders an incident pages.
  </Card>
</CardGroup>