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

# Create Incident

> Information about incident creation in Aurora

## Incident Creation

Incidents in Aurora are **automatically created** when alerts are received from integrated monitoring platforms. There is no direct POST endpoint for manual incident creation.

### How Incidents are Created

Incidents are created automatically through the following flow:

1. **Alert Reception**: Aurora receives an alert from an integrated platform (Grafana, Datadog, PagerDuty, etc.)
2. **Correlation Check**: The system checks if the alert should be correlated with an existing incident
3. **Incident Creation**: If no correlation is found, a new incident is created
4. **RCA Initiation**: Aurora automatically begins Root Cause Analysis (RCA)

### Supported Alert Sources

Aurora creates incidents from the following monitoring platforms:

* **Grafana** - `POST /api/grafana/alerts`
* **Datadog** - `POST /api/datadog/webhook`
* **Netdata** - `POST /api/netdata/alerts`
* **PagerDuty** - `POST /api/pagerduty/webhook`
* **Splunk** - `POST /api/splunk/alerts`
* **Jenkins/CloudBees** - `POST /api/jenkins/deployment` or `POST /api/cloudbees/deployment`
* **Dynatrace** - `POST /api/dynatrace/problems`
* **BigPanda** - `POST /api/bigpanda/webhook`

### Incident Schema

When an incident is created, it includes the following fields:

<ResponseField name="id" type="UUID">
  Automatically generated unique identifier
</ResponseField>

<ResponseField name="user_id" type="string">
  User who owns this incident (from the alert webhook authentication)
</ResponseField>

<ResponseField name="source_type" type="string">
  The monitoring platform that generated the alert
</ResponseField>

<ResponseField name="source_alert_id" type="integer">
  ID of the alert in the source monitoring system's database
</ResponseField>

<ResponseField name="status" type="string" default="investigating">
  Initial status is always `investigating`
</ResponseField>

<ResponseField name="severity" type="string">
  Severity level extracted from the source alert
</ResponseField>

<ResponseField name="alert_title" type="string">
  Title/summary of the alert
</ResponseField>

<ResponseField name="alert_service" type="string">
  Service or component affected
</ResponseField>

<ResponseField name="alert_environment" type="string">
  Environment where the alert occurred (production, staging, etc.)
</ResponseField>

<ResponseField name="aurora_status" type="string" default="idle">
  Status of Aurora's RCA process. Initial value is `idle`, then transitions to `running`
</ResponseField>

<ResponseField name="started_at" type="timestamp">
  When the incident started (from alert timestamp)
</ResponseField>

<ResponseField name="active_tab" type="string" default="thoughts">
  Default UI tab is `thoughts`
</ResponseField>

### Database Table Structure

Incidents are stored in the `incidents` table with the following schema:

```sql theme={null}
CREATE TABLE incidents (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id VARCHAR(255) NOT NULL,
    source_type VARCHAR(20) NOT NULL,
    source_alert_id INTEGER NOT NULL,
    status VARCHAR(20) NOT NULL DEFAULT 'investigating',
    severity VARCHAR(20),
    alert_title TEXT,
    alert_service TEXT,
    alert_environment TEXT,
    aurora_status VARCHAR(20) DEFAULT 'idle',
    aurora_summary TEXT,
    aurora_chat_session_id UUID,
    started_at TIMESTAMP NOT NULL,
    analyzed_at TIMESTAMP,
    slack_message_ts VARCHAR(50),
    active_tab VARCHAR(10) DEFAULT 'thoughts',
    created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    merged_into_incident_id UUID REFERENCES incidents(id) ON DELETE SET NULL,
    UNIQUE(source_type, source_alert_id, user_id)
);
```

### Automatic RCA Process

Once an incident is created, Aurora automatically:

1. Creates a chat session for the RCA investigation
2. Analyzes the alert payload and context
3. Generates investigation thoughts and suggestions
4. Executes diagnostic commands (if configured)
5. Provides a summary and potential remediation steps

### Correlation and Merging

If Aurora detects that a new alert is related to an existing incident:

* The alert is added to the `incident_alerts` table linked to the existing incident
* The existing incident's `correlated_alert_count` is incremented
* The alert's service is added to `affected_services` array
* No new incident is created

### Manual Incident Merging

You can manually merge incidents using the merge endpoint:

```bash theme={null}
POST /api/incidents/{target_incident_id}/merge-alert
```

Incidents can be merged via the [Update Incident](/api/incidents/update) endpoint by specifying alert correlation.

### Related Endpoints

* [List Incidents](/api/incidents/list) - GET /api/incidents
* [Get Incident](/api/incidents/get) - GET /api/incidents/{id}
* [Update Incident](/api/incidents/update) - PATCH /api/incidents/{id}

### Integration Setup

To enable automatic incident creation, configure webhooks in your monitoring platforms to point to Aurora's webhook endpoints. See the [Integrations Overview](/integrations/overview) documentation for platform-specific setup instructions.