# An alert arrived late

An outage was confirmed, but the alert didn't reach you until later than you expected. Delivery timing depends
on more than just when the outage was detected - here's what to check.

## Common causes

- **Detection itself takes a moment.** A Down alert only fires after [re-checking from other
  locations](/monitors/down-detection/) confirms the outage, which adds a few seconds beyond the very first
  failed check.
- **Channel or provider delay.** Email, SMS, and voice calls all depend on a third-party provider (your mail
  server, an SMS gateway, a phone carrier) to actually deliver the message, and that leg is outside HostTracker's
  control. Push-based channels like Slack, Telegram, or a webhook are usually near-instant once HostTracker sends
  them, but a slow or unresponsive endpoint on your side will delay (or fail) delivery too.
- **Escalation / delay settings on the contact.** If the contact or subscription is configured to wait before
  notifying (for example, only alerting after the monitor has been down for more than one check), the alert is
  deliberately held back for that window.
- **Grouped alerts.** If you've set up alert grouping to batch multiple notifications together and reduce noise,
  an individual alert can wait for the grouping window to close before it's sent.

## How to check the actual delivery time

Your account's alert delivery log (under your contacts) records every notification attempt for each contact,
including when it was sent, which channel (`gateway`) carried it, and its outcome. Compare the logged send
time against the incident's start time to see where the delay actually sits - in detection, in the
delay/escalation setting, or in delivery.

## Do it with the API

`GET /contact/notification` lists the account-wide delivery log (or `GET /contact/{id}/notification` for one
contact); each row carries `outcome` (delivered/failed/pending, distinct from a monitor's up/down `state`),
`gateway` and `checkNumber` (which check/episode it's about - use it together with `expand=monitor` to line
the send up with the incident). There's no dedicated MCP tool for the notification log yet; an MCP client with
the generic `api_request` tool can call the same endpoint directly.

## Related

- [How down detection works](/monitors/down-detection/)
- [Short outages recorded as long downtime](/troubleshooting/short-outages/)
- [Getting support](/troubleshooting/support/)