# Recheck and confirmation strategy

When a check reports a different state from the monitor's current one (Up to Down, or Down to Up), up to 7 other
locations **re-check** the target before the state changes (see
[How down detection works](/monitors/down-detection/)). The **recheck strategy** decides how their votes are
counted. The default majority vote suits almost everyone; change it when false alarms cost you more than a slightly
slower alert, or the other way round.

## Settings reference

| Setting (app label) | API field (v2) | Type / allowed values | Default | Plan limits | What it does for you |
|---|---|---|---|---|---|
| **Recheck strategy** | `recheck.strategy` | `minNumDown`, `noRecheck`, `fullAgreement`, `downFullAgreement`; `""` (empty) resets to the default | Majority vote (the field is absent or `""`) | None | How the re-check votes decide a state change. |
| **Down confirmations** (shown for the fixed-number strategy) | `recheck.minNumDown` | Integer; app 1-7, API 1-10 | 7 when you pick the strategy in the app | None | How many re-checking locations must report Down to confirm Down. |
| **Down confirmations** (Profile -> Defaults) | - (app only) | **Off**, 1, 2, 3, 5 or 7 locations | Off (majority vote) | None | New monitors created in the app start with the fixed-number strategy and this count. |

## The strategies

Every strategy counts the **clean Up** and **Down** results of the re-check. Results a checkpoint could not produce
(internal failures) are not counted.

| App option | API value | Confirms Down when | Confirms Up when | On a split |
|---|---|---|---|---|
| **DEFAULT: Vote of majority defines if new status is valid** | absent or `""` | More Down votes than Up votes | More Up votes than Down votes | A tie keeps the previous state |
| **Specified number of locations confirm Down status** | `minNumDown` (+ `minNumDown: N`) | At least N locations report Down | Fewer than N report Down and at least one reports Up | - |
| **No recheck: obtained new status is treated as confirmed** | `noRecheck` | Immediately, on the first failed check | Immediately, on the first successful check | - |
| **Full agreement: all locations should return same status to confirm** | `fullAgreement` | Every re-checking location reports Down | Every re-checking location reports Up | Any dissent keeps the previous state |
| **Full agreement for DOWN, majority vote for UP** | `downFullAgreement` | Every re-checking location reports Down | More Up votes than Down votes | A Down without unanimity keeps the monitor Up |

### Choosing

- **Majority** (default) - balanced; one flaky location or network path cannot page you on its own.
- **Fixed number of Down confirmations** - an explicit, predictable bar, for example "3 locations must see it".
  Lower numbers alert faster on regional problems; 7 means every re-checking location must agree.
- **Full agreement** or **Full agreement for DOWN** - the fewest false alarms, but a real outage that only some
  regions see may never be confirmed.
- **No recheck** - the fastest alert and the most exposed to one bad checkpoint. Useful for testing, rarely for
  production.

## Set it up in the app

1. On **Sites**, open the monitor and expand **Monitoring Locations**.
2. Under **Recheck strategy**, choose an option.
3. For **Specified number of locations confirm Down status**, set **Down confirmations** with the slider (1-7).
4. **Save**.

To start every new monitor with a fixed number of confirmations, set **Profile -> Defaults -> Down
confirmations**.

## Do it with the API or MCP

```bash
# Require 3 locations to confirm Down (scope monitor:write)
curl -X PATCH "https://api2.host-tracker.com/monitor/$MONITOR_ID" \
  -H "Authorization: Bearer $HT_TOKEN" -H "Content-Type: application/json" \
  -d '{ "recheck": { "strategy": "minNumDown", "minNumDown": 3 } }'

# Back to the majority vote
curl -X PATCH "https://api2.host-tracker.com/monitor/$MONITOR_ID" \
  -H "Authorization: Bearer $HT_TOKEN" -H "Content-Type: application/json" \
  -d '{ "recheck": { "strategy": "" } }'
```

Omit `recheck` to leave the current strategy unchanged. Read it back with `GET /monitor/{id}` (the `recheck`
member, present with the default `expand=settings`). Many monitors: `POST /monitor/bulk-update` with
`{ "patch": { "recheck": { ... } } }`. MCP: the curated tools have no recheck argument - use **`api_request`**
(`PATCH /monitor/{id}`) or **`bulk_update_monitors`** with `patchJson` `{"recheck":{"strategy":"minNumDown","minNumDown":3}}`.

## What happens next

The strategy applies to the next state change. It does not re-evaluate past incidents.

## Limits and gotchas

- **Which types use it.** The strategy applies to Website/HTTPS, API, Ping, Port, Page speed and Transaction
  monitors. Database, SNMP, Counter, DNSBL, Domain expiry, Web Risk and Site crawl monitors decide on a single
  result and never recheck. Web content check monitors always use the majority vote - the editor shows the
  selector, but the choice is not stored for that type.
- **The recheck asks at most 7 locations.** `minNumDown` values 8-10 are accepted by the API but can never be
  reached, so Down would never be confirmed. Keep it at 7 or below.
- `minNumDown` outside 1-10 is refused (`422`, "Number of locations should be in [1,10] range"); `strategy:
  "minNumDown"` without a number is refused too.
- Fewer locations mean fewer votes: with a narrow [location](/monitors/default-locations/) selection, a strict
  strategy can take longer to confirm or never confirm a partial outage.

## Related

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