Troubleshoot alert delivery

Use the alert timeline to isolate ingest, routing, and delivery failures.

1. Did the alert arrive at all?

Open Alerts. If the alert is missing, inspect the sender's HTTP response and logs.

A 401 means the credential is invalid or revoked. A 400 response describes a malformed signal. A 202 with "buffered":true means the edge accepted the signal for asynchronous processing; use its alert_id if you contact support.

2. Was it deduplicated onto an existing alert?

A signal with the same service and event_key joins the existing open alert. The dedupe count increases. Acked does not page again unless the duplicate raises the priority.

Look for an open alert with a dedupe count above one. Use distinct event keys when occurrences must open separate alerts. See Sending alerts.

3. Was anyone on call?

Open the service and its schedule. Confirm that a user is on call at the alert's creation time.

unreachable means no responder could be selected or the configured escalation passes completed without acknowledgement. The timeline records the reason.

4. Review delivery attempts

The alert timeline lists the channel, target, and provider result for each delivery attempt.

5. It says sent, and my phone was silent

A sent result confirms provider acceptance, not display or sound on the handset. Check:

6. It arrived, late

Compare the alert creation time with the first delivery attempt. Later attempts follow the configured reminder and escalation cadence.

Still wrong?

Email support@acked.dev with the organization name and alert id.