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

# The alert arrived but no incident was created

> Ingestion returned 202 but nothing showed up under Incidents.

A `202` means the alert was **accepted and recorded** — not necessarily that it created an incident. There are legitimate reasons for that.

## 1. The alert was aggregated into an existing incident

This is the most common cause, and it is the correct behavior.

If an **open** incident already exists for the same origin and service, the new alert is attached to it. Open the existing incident and check the timeline: there should be an alert-aggregated event.

<Tip>
  Check resolved incidents too: if you resolved an incident while the alert kept firing within the same window, it is easy to lose track of which incident is open.
</Tip>

## 2. The state sent does not open an incident

Each source type has states that are deliberately ignored:

| Source          | Ignored states                                  |
| --------------- | ----------------------------------------------- |
| Grafana         | `paused`, `pending`, `no_data`                  |
| Datadog         | `Renotify`                                      |
| CloudWatch      | `INSUFFICIENT_DATA`                             |
| Generic webhook | Any `status` other than `firing` and `alerting` |

<Warning>
  On the generic webhook, sending `"status": "resolved"` makes the alert be accepted with `202` and **discarded** — no incident is created and none is resolved. The generic webhook does not support auto-resolution.
</Warning>

## 3. A recovery event arrived with no open incident

If the tool sent a recovery (`resolved`, `OK`, `Recovered`, `CLOSED`) and there was no matching open incident, aciona.me records the alert and does nothing. That is intentional: no error, no incident.

## 4. The source type does not match the payload

A `Generic` source receiving a Grafana payload accepts the request but reads the wrong fields. Check that the source type matches the tool sending the data.

## 5. The service could not be resolved

If the alert carries no service hint and the source has no default service, routing has no destination. Configure a **default service on the source**, or make sure the tool sends the service hint.

## How to investigate

<Steps>
  <Step title="Filter incidents by service and period">
    Include resolved and closed incidents in the search.
  </Step>

  <Step title="Open the nearest open incident">
    Look on the timeline for an alert-aggregated event at the time you sent it.
  </Step>

  <Step title="Re-send with a new externalId">
    A different `externalId` forces a separate incident — if it shows up, it was aggregation.
  </Step>
</Steps>