# 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](/troubleshooting/short-outages/) - here the *alert itself* fired for
something that barely lasted a moment.

## Why it happens

HostTracker doesn't wait around before confirming an outage. The moment a check fails, it
[re-checks from several other locations](/monitors/down-detection/) 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

- **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](/monitors/down-detection/).
- **More locations.** A monitor re-checking from a small pool needs fewer failures to reach "majority." Widening
  your [monitoring locations](/monitors/default-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](/troubleshooting/short-outages/)
  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

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

## Related

- [Short outages recorded as long downtime](/troubleshooting/short-outages/)
- [How down detection works](/monitors/down-detection/)
- [Set your default locations](/monitors/default-locations/)