What it can be
A problem on the path between that region and the site, a failing CDN edge node, a DNS resolver problem in that region, a block of the monitor’s addresses, or the early minutes of a real outage that has not yet reached the other region. Visitors in that region may be affected for real. Other tools treat the same situation as a vote or a warning: Amazon’s Route 53 considers an endpoint healthy while more than 18 percent of its health checkers report it healthy, a threshold AWS says it chose so that an endpoint is not judged unhealthy only because network conditions have isolated it from some checking locations, and Oh Dear’s documentation marks a run as a warning, not a failure, when the primary location fails and the secondary succeeds (both read 2026-10-28).
How to treat it
Do not wake anyone, and do not ignore it. Agree with the client what a regional issue triggers: a chat message, a look within the hour, a note in the monthly report. If the client’s visitors are concentrated near the failing region, treat it more seriously.
An example
A monitor shows the Frankfurt region failing for four minutes while Amsterdam passes. The stored evidence shows Frankfurt resolving the site’s name to an old address, while Amsterdam resolved the new one: a DNS change that one resolver has not yet picked up. There was no outage, but the record had changed. A regional issue that lasts longer than the record’s TTL points elsewhere: a routing problem, a CDN edge or a block of the monitor’s addresses.
What to check
Where the client’s visitors are, whether a monitoring region is near them, how often regional issues recur in the same region and what the evidence from each region shows.
Sources
Read on . Standards and vendor pages change; confirm the current text before you rely on it.