Skip to main content
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.
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.

​
2. The state sent does not open an incident

Each source type has states that are deliberately ignored:
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.

​
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

1

Filter incidents by service and period

Include resolved and closed incidents in the search.
2

Open the nearest open incident

Look on the timeline for an alert-aggregated event at the time you sent it.
3

Re-send with a new externalId

A different externalId forces a separate incident — if it shows up, it was aggregation.