A brief network blip alerted me
You watched the site come right back, but you still got a Down alert. This is different from short outages recorded as long downtime - here the alert itself fired for something that barely lasted a moment.
Why it happens
Section titled “Why it happens”HostTracker doesn’t wait around before confirming an outage. The moment a check fails, it re-checks from several other locations right away. If enough of them also fail in that same instant - a real, if brief, network hiccup that happened to affect multiple paths at once - the outage is confirmed and the alert goes out immediately. There’s no cool-down built in by default: a confirmed down is a confirmed down, however short it turns out to have been.
The levers that make this less sensitive
Section titled “The levers that make this less sensitive”- Confirmation strategy. By default a majority of re-checking locations decides. Switching a monitor to full agreement means every re-checking location has to fail before the state changes - a wider blip is needed to trigger an alert. See How down detection works.
- More locations. A monitor re-checking from a small pool needs fewer failures to reach “majority.” Widening your monitoring locations makes a one-off local problem less likely to swing the vote.
- Timeout. If the blip shows up as slowness rather than a hard failure, a slightly higher timeout can let the check succeed instead of timing out. See Short outages recorded as long downtime for the trade-off that comes with raising it.
- Alert delay per contact. Some alert channels can be configured to only notify after the monitor has stayed down for more than one check cycle, rather than on the very first confirmed Down. This trades a few seconds of alert latency for fewer notifications about outages that resolve on their own.
How to verify what happened
Section titled “How to verify what happened”Open the incident in the app, or read it through the API: GET /monitor/incident/{id}?expand=recheck returns
detectedBy (the first failing check), confirmations[] (each re-checking location’s error and locations
list) and unconfirmed[] - so you can see exactly how many locations agreed and how fast, rather than
guessing from the alert alone. An MCP client reads the same detail with get_incident.