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
Section titled “Common causes”- Detection itself takes a moment. A Down alert only fires after re-checking from other locations 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
Section titled “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
Section titled “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.