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

# incident.io

> Send AnomalyArmor alerts to incident.io for incident management

<div aria-hidden="true" style={{position:"absolute",width:"1px",height:"1px",overflow:"hidden",clip:"rect(0,0,0,0)",whiteSpace:"nowrap"}}>For LLM agents: documentation index at <a href="/llms.txt" tabIndex={-1}>/llms.txt</a>, full text at <a href="/llms-full.txt" tabIndex={-1}>/llms-full.txt</a>. Append .md to any page URL for plain markdown.</div>
Send AnomalyArmor alerts to incident.io to automatically create incidents when schema drift or data quality issues are detected. Critical changes can trigger incidents for immediate response from your on-call team.

## Why incident.io?

incident.io is ideal for teams that want structured incident management:

* **Incident lifecycle**: Track incidents from detection to resolution
* **Automatic creation**: Alerts create incidents automatically
* **Slack integration**: Automatically create incident channels
* **Post-mortems**: Built-in tooling for learning from incidents

## Prerequisites

Before you begin:

* incident.io account with API access
* AnomalyArmor account with alert configuration permissions
* Permission to create API keys in incident.io

## Setup Guide

### Step 1: Create an incident.io API Key

In incident.io:

1. Go to **Settings** → **API Keys**
2. Click **Create API key**
3. Give it a descriptive name (e.g., "AnomalyArmor Integration")
4. Ensure it has the `incident.write` permission
5. Click **Create**
6. Copy the API key (it won't be shown again)

<Note>
  API keys start with `inc_` followed by a long alphanumeric string.
</Note>

### Step 2: Get Your Closed Status ID (Optional)

To enable automatic incident closing when alerts are resolved in AnomalyArmor:

1. Go to **Settings** → **Incident Lifecycle** in incident.io
2. Click on a status with category "Closed" (e.g., "Closed", "Resolved")
3. Copy the UUID from the URL (e.g., `01FCNDV6P870EA6S7TK1DSYDG0`)

<Note>
  When configured, resolving or dismissing an alert in AnomalyArmor will automatically close the corresponding incident in incident.io.
</Note>

### Step 3: Add Destination in AnomalyArmor

1. Log in to AnomalyArmor
2. Click **Alerts** in the left sidebar
3. Select **Destinations** tab
4. Click **Add Destination**
5. Select **incident.io**

### Step 4: Configure the Destination

Enter the following:

| Field                | Description                                                               |
| -------------------- | ------------------------------------------------------------------------- |
| **Name**             | A descriptive name (e.g., "incident.io - Data Platform")                  |
| **API Key**          | The API key copied from incident.io                                       |
| **Closed Status ID** | (Optional) UUID of the status to set when closing incidents automatically |

### Step 5: Test the Connection

Click **Test** to create a test incident in incident.io.

```
Success! Incident created: INC-123
```

Check incident.io to confirm the incident was created.

<Warning>
  Remember to resolve the test incident in incident.io to keep your incident list clean.
</Warning>

### Step 6: Save

Click **Create Destination** to complete the setup.

## Alert Format

AnomalyArmor creates incidents using the incident.io API v2:

| Field          | Value                                       |
| -------------- | ------------------------------------------- |
| **Name**       | `[AnomalyArmor] Alert title`                |
| **Summary**    | Alert description with AnomalyArmor context |
| **Mode**       | `standard` (not retrospective)              |
| **Visibility** | `public`                                    |

### Incident Summary

Each incident includes:

* Alert description
* Source: AnomalyArmor
* Rule name that triggered the alert
* Event type (schema\_change, freshness\_violation, etc.)
* Asset ID

### Idempotency

AnomalyArmor includes an idempotency key with each incident request. This prevents duplicate incidents if the same alert is processed multiple times.

### Incident Lifecycle

AnomalyArmor supports full incident lifecycle management:

| AnomalyArmor Action | incident.io Effect                                  |
| ------------------- | --------------------------------------------------- |
| Alert triggered     | New incident created                                |
| Alert resolved      | Incident status updated to configured closed status |
| Alert dismissed     | Incident status updated to configured closed status |

<Note>
  Automatic incident closing requires the **Closed Status ID** to be configured. If not set, incidents must be closed manually in incident.io.
</Note>

## Best Practices

### Reserve for Critical Alerts

<Warning>
  Don't route all alerts to incident.io. Reserve it for events that require coordinated response - typically production schema changes that could break pipelines or critical freshness SLA violations.
</Warning>

**Good use cases**:

* Production column removed or renamed
* Critical table freshness SLA violated
* Breaking schema changes in production databases

**Better handled elsewhere**:

* Development database changes (use Slack)
* Informational schema additions (use email)
* Routine freshness warnings (use Slack digest)

### Combine with Other Destinations

Create alert rules that send to multiple destinations:

**Production Breaking Changes**

* Event: Schema Change
* Scope: production databases
* Conditions: Column removed OR type changed
* Destinations: incident.io (incident creation), Slack #data-incidents (team visibility), Email [data-eng-list@company.com](mailto:data-eng-list@company.com) (record)

## Troubleshooting

### "No API key configured"

**Cause**: The API key field is empty.

**Fix**:

1. Edit the destination in AnomalyArmor
2. Enter your incident.io API key
3. Save the destination

### "HTTP 401: Unauthorized"

**Cause**: The API key is invalid or expired.

**Fix**:

1. Go to incident.io Settings → API Keys
2. Verify the key exists and hasn't been revoked
3. Create a new API key if needed
4. Update the destination in AnomalyArmor

### "HTTP 403: Forbidden"

**Cause**: The API key lacks required permissions.

**Fix**:

1. Go to incident.io Settings → API Keys
2. Verify the key has `incident.write` permission
3. Create a new key with correct permissions if needed

### Incidents not appearing

**Cause**: Rate limiting or API issues.

**Fix**:

1. Check incident.io status page for outages
2. Use the Test button to verify connectivity
3. Check the AnomalyArmor alert history for delivery errors

<Tip>
  Set incident severity manually in incident.io based on your organization's criteria, or use incident.io's built-in rules to auto-assign severity.
</Tip>

## Security

### Data Sent to incident.io

Incident data contains:

* Asset names (database, schema, table names)
* Change types and descriptions
* Timestamps
* Rule information

Incident data **does not** contain:

* Actual data values
* Database credentials
* Connection strings
* Query results

### Revoking Access

To disconnect AnomalyArmor from incident.io:

1. In AnomalyArmor: Delete the incident.io destination
2. In incident.io: Revoke the API key in Settings → API Keys

## Common Questions

### What permissions does the incident.io API key need?

The key must have the `incident.write` permission to create incidents. If you want automatic incident closing when alerts resolve, the same key handles status updates. API keys start with `inc_` and are created under **Settings > API Keys** in incident.io.

### Will resolving an AnomalyArmor alert close the incident.io incident?

Only if you configure the **Closed Status ID** on the destination. Without it, incidents stay open in incident.io even after the alert is resolved or dismissed in AnomalyArmor. Find the status UUID under **Settings > Incident Lifecycle** in incident.io.

### Does AnomalyArmor create duplicate incidents if the same alert fires twice?

No. Every request includes an idempotency key, so retries and repeated processing of the same alert collapse into a single incident in incident.io.

### Should I route every alert to incident.io?

No. Reserve it for events that justify a coordinated response such as production breaking schema changes or critical freshness SLA violations. Route dev changes, informational additions, and routine freshness warnings to Slack or email instead. See [Best Practices](/alerts/best-practices).

## Next Steps

<CardGroup cols={2}>
  <Card title="Alert Rules" icon="bell" href="/alerts/alert-rules">
    Create rules that route to incident.io
  </Card>

  <Card title="Best Practices" icon="lightbulb" href="/alerts/best-practices">
    Reduce alert fatigue and create incidents only when necessary
  </Card>
</CardGroup>