Multi-Region Probes and Quorum Confirmation

Failures that are only visible from somewhere else

A meaningful share of production incidents are not global. A BGP route leak affects one continent. A CDN edge node serves stale or broken content in one metro. A geo-DNS rule sends an entire country to a decommissioned origin. A regional cloud zone degrades.

From a single probe location, every one of those looks like a perfectly healthy service — while a real segment of your users cannot load the page at all.

• BGP and routingPath changes that black-hole traffic from specific networks or continents.
• CDN edge failuresOne point of presence serving errors or stale objects while others are fine.
• Geo-DNS mistakesA misconfigured region record pointing part of the world at the wrong origin.
• Regional cloud incidentsProvider-level degradation in a single zone or region.

How quorum works

When a probe in one region reports a failure, SutramX retries that check once from the same region about two seconds later. That single result still does not open an incident on a multi-region plan: enough regions have to record the failure first.

If the required number of regions agree the endpoint is failing, the monitor goes down and alerts dispatch. If they disagree — one region failing while others succeed — the event is classified as a regional anomaly. It appears in your history and per-region latency views, but it does not page anyone, because at least one independent region could still reach your service.

Reading per-region latency

Beyond up and down, the per-region view is a practical CDN audit. If one region consistently sees three times the latency of another, your edge configuration is probably not doing what you think it is for users near the slow region.

Comparing regional latency over time is also how you verify that a CDN change, a new origin location, or a routing tweak actually helped the users it was supposed to help.