Where PageLantern checks run from.

A monitor has an ordered, fixed set of probe locations. Each selection runs on every interval and keeps an independent latency measurement. The first location drives the monitor summary; the remaining results provide regional evidence without racing the global state.

The known weakness of a single vantage point is the false positive: a routing hiccup between our region and your host looks exactly like your site being down. That is where PageLantern adds geography — as a targeted second opinion at the moment of failure, not as always-on background load. Two things have to be true for it to engage: the monitor has to be set to the second-region confirmation policy (it is not the default), and a remote confirmation location has to be live. When both hold, a check that crosses its failure threshold has its incident held while the same check is re-run from a different region before anyone is paged.

Failure confirmation is a per-monitor setting in the monitor composer. The default is "Alert after 2 consecutive failures" — a purely home-region policy. "Confirm from second region before alert" is the opt-in third option, and it is offered only on the check types a remote location can reproduce.

With that policy selected, a home-region failure does not open an incident immediately. The check is re-run from a remote confirmation location, and the held incident resolves one of three ways: confirmed — the second region also saw the failure, so the incident opens, annotated with the confirming location; refuted — the second region found the target healthy, so the failure is treated as a local network artefact and nobody is paged; or timed out — no remote answer arrived in time, so PageLantern trusts its home vantage and opens the incident, annotated as single-source. If the home region recovers while confirmation is pending, nothing opens at all.

Confirmation locations are satellites that report heartbeats to the hub, and the gate only uses locations that are enabled and heartbeating recently. When none is available — which was the case for the whole single-region history of the product — selecting the policy changes nothing: checks run from the primary region and incidents open on the home vantage exactly as they always have. Timing out toward "open the incident" rather than suppressing it is the same deliberate choice: a confirmation outage must never eat a real alert.

Some monitoring products probe every check continuously from dozens of global locations and report per-location latency. PageLantern does not, and this page should say so as plainly as the pricing page says the price: we do not run every check from many regions, we do not report per-region latency, and we do not sell a world map. If you need per-geography performance measurement — "how fast is the site from Sydney" — a synthetic measurement product is the right tool.

What single-region probing plus second-region confirmation does buy: alerting that is cheap enough to include generously on every plan, and a false-positive story aimed at the actual failure mode of single-vantage monitors. The second region exists to stop wrong pages, which is the job.

Probes identify themselves with a User-Agent containing the substring PageLantern-Probe and a contact URL. If you allowlist, match that substring — never our IP addresses, which can change when we deploy. When a target's bot protection or rate limiting refuses a probe, PageLantern scores the response as "not measured" rather than inventing a verdict, and raises a probe-blocked incident if the refusal persists. The operational states guide documents the whole model with per-platform allowlist rules.