> ## 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.

# Test an alert source

> Validate the integration end to end before relying on it in production.

Before trusting an integration, run a full test: alert sent, incident created, notification received and — where the tool supports it — automatic resolution.

## Quick test

Works with any source type to validate **credentials and connectivity**:

```bash Connectivity test theme={null}
curl -i -X POST "https://ingress.aciona.me/webhooks/<alertSourceId>" \
  -H "Content-Type: application/json" \
  -H "X-Aciona-Token: <sourceToken>" \
  -d '{
    "externalId": "connectivity-test",
    "title": "Integration test",
    "severity": "info",
    "service": "payments-api",
    "status": "firing"
  }'
```

Expected response: `HTTP/1.1 202 Accepted`.

<Note>
  With `info` severity, aciona.me creates the incident but **does not send push** — that is normal behavior for informational alerts. Use `critical` if you want to validate the notification on your phone.
</Note>

## Full test

<Steps>
  <Step title="Trigger from the tool itself">
    Use its native test feature (test notification, test workflow, force alarm state) or force the alert condition. That validates the **real payload**, not one you made up.
  </Step>

  <Step title="Confirm the incident">
    Under **Incidents**, check title, severity, service and owner. If the service is wrong, adjust the service hint the tool sends.
  </Step>

  <Step title="Confirm the notification">
    You should receive it through the configured channels. If not, see [Notification not received](/en/troubleshooting/notification-not-received).
  </Step>

  <Step title="Acknowledge the incident">
    Validate that ACK works through the channel your team actually uses — push, email or the Slack card.
  </Step>

  <Step title="Test the recovery">
    Bring the condition back to normal (or force the recovery) and confirm the incident was resolved **automatically**. This is the most-skipped step — and the one that fails most often in production.
  </Step>
</Steps>

## Validation checklist

* [ ] `202 Accepted` on ingestion
* [ ] Incident created with the correct service
* [ ] Severity translated as expected
* [ ] Owner resolved by the schedule
* [ ] Notification received on the right channel
* [ ] ACK working through the team's channel
* [ ] Second trigger **aggregated**, not duplicated
* [ ] Recovery resolving the incident automatically

<Card title="Something did not work?" icon="life-buoy" horizontal href="/en/troubleshooting/overview" />