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

# 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 selection, a strict strategy can take longer to confirm or never confirm a partial outage.

Related

• How down detection works
• Choose monitoring locations
• Short outages recorded as long downtime