Confirmation regions & failure thresholds

A single failed check from a single region doesn’t mean your service is down. It might mean:

A specific cloud region had a 30-second hiccup.
Your CDN’s edge node misbehaved for one request.
A transient DNS resolver glitch.
A real outage.

PathWatch uses confirmation logic on alert rules to distinguish these. The default settings already cover the common case; this page explains the knobs for when you need finer control.

Two thresholds

Every alert rule has two confirmation knobs:

Consecutive failures — how many failed checks in a row, from any combination of regions, before the rule fires. Default 1. Higher values trade alert latency for fewer false positives.
Confirmation regions — array of region ids. If set, the rule fires only when failures from these specific regions match the consecutive-failures threshold. If empty (default), any region’s failures count.

Set both via the alert rule editor at Alerts → Rules → New rule → Confirmation.

Default behaviour

Out of the box: 1 consecutive failure, no region restriction.

First failure from any monitored region fires the alert.
Lowest latency, highest noise.
Fine for monitors with 1-minute or longer intervals on stable services. The check itself takes 5-30 seconds; a single failure there is a real signal.

Tuning by check interval

A useful rule of thumb:

Interval	Recommended consecutive failures
30 s	3 (1.5 min before alert)
1 min	2-3 (2-3 min)
5 min	1-2 (5-10 min)
1 h+	1 (waiting longer defeats the point)

You’re trading detection time against noise. The right number depends on how often your service genuinely twitches.

Cross-region confirmation

Coming soon. Cross-region confirmation is accepted and saved on alert rules today, but does not yet affect evaluation — alerts currently fire on consecutive_failures from any region. The behaviour described below ships when region-scoped evaluation is enabled; existing rules will pick it up automatically.

For high-stakes alerts, require multiple regions to agree before firing:

Set the monitor to check from at least 3 regions.
Set the alert rule’s Confirmation regions to a subset of those (typically all of them).
Set Consecutive failures to 1.

Now the rule fires only when EVERY listed region reports a failure in the same check window. A single-region outage on the cloud provider’s side doesn’t page you.

The trade-off: detection latency rises to the slowest region’s check time, and a regional outage on the test infra itself (rare but happens) suppresses alerts for the duration.

Combining the two

consecutive_failures: 2 + confirmation_regions: ["us-virginia", "gb-london"] means:

Both Virginia AND London must fail.
Both must fail twice in a row.
THEN the alert fires.

This is the strictest config — useful for the “wake up the on-call at 03:00” alert rules where false positives are very expensive. Reserve it for top-priority alerts; layer noisier rules on top for the “investigate in the morning” tier.

Recovery

A single successful check from a confirming region transitions the alert state back to ok. There’s no “consecutive recoveries” threshold — the assumption is that a real recovery beats holding the page open.

If you want to delay the recovery notification (let the service prove stability), use a maintenance window for the first 5 minutes post-incident; alerts stay suppressed and the recovery notice goes out cleanly.

Acknowledgement + suppression

Acknowledging an alert (via the Active Alerts panel at /alerts) stops escalation and recurring reminders for the current alert state. It does NOT reset the confirmation counter — if the underlying failures continue, the alert state stays alerting, just silently.

Maintenance windows suppress alert evaluation entirely for the covered monitors. Failures during a window don’t increment the confirmation counter; the counter resumes from where it was when the window ends.

When to skip confirmation

A few cases where defaults beat tuning:

Single-region monitors — confirmation regions can’t help if there’s only one region. Tune consecutive failures only.
Heartbeat monitors — they’re already time-window based; consecutive failures don’t apply.
Hard binary checks (SSL expiry, domain expiry) — the check is yes/no on a slow-changing fact. One failure is enough.