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

# Incidents

Auto-created from monitor downtime, manually created from the dashboard or API, with severity, ack, escalation, and timeline updates.

# Incidents

An incident is a record of an outage or service disruption. Each incident has a status (`investigating`, `identified`, `monitoring`, `resolved`), a severity (`minor`, `major`, `critical`), affected monitors, a timeline of updates, and audit fields for acknowledgement and resolution.

## How they get created

**Auto-created from monitor downtime**

When a monitor's confirmed status flips to `down` and there is no active incident for that monitor, the auto-create path runs:

    1. Insert `incidents` row with `auto_created = 1` and `source_monitor_id` set.
    2. Link the monitor via `incident_monitors`.
    3. Add an "investigating" update with details.
    4. Severity inferred from how many regions failed:
       - All regions failed → `critical`
       - 2+ regions failed → `major`
       - 1 region failed → `minor`
    5. If a deploy correlation exists (GitHub repo linked), annotate with the suspect commit.
    6. If the org has a schedule with an escalation policy, start the escalation timer.

  **Manually from the dashboard or API**

POST `/incidents` with `title`, optional `severity`, and `affected_monitors`. The first update is created automatically.

## Acknowledgement & escalation

When an incident exists with an active escalation policy, a per-minute cron checks: has anyone acked? If not and the next level's `delay_minutes` has elapsed, the dispatcher fires a notification to that level's target (user / schedule / channel) and bumps `current_level`.

Acking happens via:
- Dashboard "Acknowledge" button
- Slack interactive button (`Acknowledge` on the alert message)
- `/happyuptime ack <id-or-title>` slash command
- `POST /incidents/:id/ack`

Acking sets `acknowledged_at` and `acknowledged_by`, and stops escalation.

## Auto-resolution

When a monitor recovers (confirmed `up`), Happy Uptime:

1. Adds a "resolved" update with downtime duration.
2. If all linked monitors are up, sets `incidents.status = 'resolved'` and `resolved_at = now`.
3. Stops any pending escalation.
4. Purges the status page edge cache so subscribers see green again.

## Updates timeline

Each incident has a stream of updates (`incident_updates` table) — same model PagerDuty / status pages use. Updates have a `status` (matches the incident status enum), a `message`, optional `is_internal` flag (visible only to team), and an author.

Add updates via:
- Dashboard "Add Update" button
- `POST /incidents/:id/updates`
- AI: `POST /ai/draft-update` to generate update copy from the incident's history

## Quick links

**[Incident API](/api/incidents/list)**

Full CRUD.
  **[Escalation policies](/guides/escalation-policies)**

Define what happens when nobody acks.
  **[Status page incidents](/concepts/status-pages)**

Surface incidents on your customer-facing page.
  **[AI postmortem](/api/overview)**

Generate a post-incident report from the timeline.