Require N failed checks before alerting

With the default threshold of 1, an HTTP check alerts you on its first failed check, once any recheck has failed too. For a noisy target (a flaky third-party dependency, an endpoint behind an aggressive bot-management edge), set confirmation_threshold to N and the monitor only transitions to failed after N consecutive failed checks.

Set it

1. Open the monitor, choose Edit monitor and set Confirmation Threshold under Alerting (1 to 10, default 1), or send the field through the API, with an API key exported as SITEQWALITY_API_KEY and $JOB_ID set to the check’s id:

   curl -X PUT https://api.siteqwality.com/http/job/$JOB_ID \
     -H "Authorization: Bearer $SITEQWALITY_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{ "confirmation_threshold": 3 }'

2. Work out what it costs you in detection time. The alert fires on the Nth failed check itself, so:

   time to alert after the first failed check = (N - 1) × interval
   worst-case detection latency from the outage starting = N × interval

   A 60 second monitor at threshold 3 alerts about 2 minutes after the first failed check, and at worst 3 minutes after the site actually went down. Pick the threshold against the interval, not in isolation.

Unconfirmed failures are still recorded

The threshold gates the state transition, not the check. A failed-but-unconfirmed check still lands in the check results, the per-phase performance record and the per-location status. It shows as a failure in Recent checks, and it still drags down the 24 hour uptime ratio, the daily rollup and therefore SLA reports. A failure that passes its recheck is the exception: the recheck’s result is recorded in its place.

What waits for confirmation:

• the flip to failed status;
• notifications to every channel in the monitor’s groups, and the delay_send_after_minutes and resend_every_minutes timers;
• automatic incident creation, and the escalation that hangs off it;
• the downtime window used by GET /http/job/{job_id}/uptime_percentage.

Because the downtime window opens at confirmation time, an outage’s recorded duration is up to (N - 1) × interval shorter than the raw check history suggests. Uptime as a ratio of checks counts every failed check; uptime as a duration counts confirmed downtime.

Recovery is not threshold-gated

One successful check that satisfies the location quorum closes the state transition immediately, whatever the threshold. The all clear and automatic incident resolution wait only for the monitor’s recovery period.

How it composes with the other failure filters

Four layers sit between a network blip and your phone, in this order:

1. transport retry     inside a single check
        ↓
2. location quorum     decides whether one check evaluation counts as failed
        ↓
3. recheck             checks each failed location once more, then the quorum decides again
        ↓
4. confirmation        counts consecutive failed evaluations

With one check location, layer 2 is a 1-of-1 pass-through and only layers 1, 3 and 4 do any work.

1. Transport retry, inside one check

Before it records anything, the check retries fast transient transport failures up to 2 times: connection reset, TLS failure, TCP connect failure, DNS failure and generic connection failure. Timeouts are not retried, and neither is any deterministic response failure (a wrong status code, a missing keyword, an unexpected final URL).

A check that succeeds on retry is recorded as a plain success, so it also resets any confirmation streak.

2. Location quorum

min_healthy_regions decides whether a single evaluation counts as failed: every selected location runs on the same tick, and the evaluation is healthy when at least that many of them passed.

A location that cannot return a result in a run (its provider is unreachable, for example) is left out of that evaluation, and min_healthy_regions is capped at the number of locations that did report. A monitor set to three locations with min_healthy_regions: 2 whose third location is unreachable is evaluated as 2 of 2 for that run, not failed. If no location reports a result, the monitor’s status stays unchanged. See check locations.

With two or more locations, a run where only one location answered and it failed is inconclusive: its result is recorded, but the status does not change. If the next run is inconclusive too, the monitor is decided on what answered and the outage is marked degraded_quorum. One passing answer is enough to stay healthy.

A run that passes the quorum while some locations fail leaves the monitor up. The monitor shows Failed in 1 of 2 locations (for example) until a run passes everywhere, and nobody is paged.

3. Recheck before alerting

recheck_on_failure gives a failed run one more chance before it counts. When a run fails the location quorum while the monitor is up, each location that failed is checked once more, and the run is judged on those answers:

Value	Each failed location is checked again
off	Never. The failure counts as it is.
same_location	From the same location, about 5 seconds later.
another_cloud	Straight away, from a healthy location on another cloud provider in the same country (the same city first) that the monitor does not already run from. When no other provider there can run the check, or the plan no longer includes it, the same location checks again instead.

A recheck never leaves the country of the location that failed. If the rechecks bring the run up to the quorum, it passes and nobody is alerted. Otherwise the run counts as failed, and the inconclusive rule above, the confirmation threshold, flap hold and the notification group’s delay and repeats apply to it as usual. A recheck that returns no result keeps the failure.

The recheck’s result replaces the failure in the run’s results, under the id of the location that ran it, so a failure its recheck clears does not count against uptime. Each recheck writes a recheck monitor event with the first failure’s reason and status code and the outcome.

• Only an up monitor is rechecked. A monitor that is already down is not, so it recovers on its first passing check. A run that passes the quorum while some locations fail is not rechecked either.
• Each recheck is a check. A recheck that returns a result counts as one check toward your monthly check volume, and only a failure triggers one.
• Defaults and plans. A monitor created without the setting gets another_cloud on a paid uptime plan when another cloud provider can run the check, otherwise same_location. Ping runs on one cloud provider, so a ping check gets same_location. Monitors created before the setting existed have off. another_cloud needs a paid uptime plan, like more than one location; same_location works on every plan. Send recheck_on_failure on create or update; the field reference has the details.

4. Confirmation threshold

The threshold then counts how many consecutive ticks the quorum verdict, after any recheck, has failed for: with one location, the last N checks all failed. Any tick at which the quorum was healthy resets the streak.

Tip

To skip only blips that clear within a minute, delay_send_after_minutes on the notification group is often the better tool: the group’s down alert waits, then sends only if the monitor is still down. It holds back the group alert only; on a monitor linked to a service, the incident still opens on the first failure.

What it does not cover

Browser checks have their own confirmation_threshold and rerun_on_failure, and are not rechecked this way; see rerun and confirmation. Cron, DNS and TLS checks alert on the first failure.

The TLS, DNS, and page-speed monitors that get provisioned alongside an HTTP check do not inherit the parent’s threshold or recheck.

See also

HTTP check reference Every field on an HTTP check, with defaults and limits.

Notification groups delay_send_after_minutes and resend_every_minutes.

Incidents What a service opens when a confirmed failure lands.