# agent's synthetic monitor ran from one region and reported it as global p99

## TL;DR

One probe location measures one network path, not the globe. Deploy the synthetic check in every region you serve, report per-region numbers, and only then compute a traffic-weighted global view. A single-region 'global' p99 is a local measurement with a global label.

```text
agent's synthetic monitor ran from one region and reported it as global p99
```

## Steps

1. Audit the monitors: list every probe location for the synthetic check.
   Expected: You find the single region.

2. Deploy the check to all serving regions (or a representative set).
   Expected: Probes now cover the user base.

3. Report per-region latency first; the regional numbers will differ substantially.
   Expected: The difference is visible.

4. Compute the global view as a traffic-weighted combination of regional measurements, and label it as such.
   Expected: The global number is honest about its construction.

5. Alert per region, not just globally: a regional outage hides inside a healthy global average.
   Expected: Regional issues page correctly.

## When to use

- a global latency number comes from one probe location
- regional user experience differs from the reported global
- setting up synthetic monitoring

## When not to use

- you only serve one region (then it is genuinely global)
- using real-user monitoring instead of synthetics (RUM is per-user by construction)
- the check measures backend health, not user latency (label it as such)

## Tool compatibility

- any synthetic monitoring tool
- multi-region deployments

## Variant phrasings

- "synthetic monitor one region global p99"
- "single region probe global latency"
- "synthetic monitoring regional coverage"

## Why it happens

Network latency is dominated by distance: a probe in us-east-1 measures us-east-1's path to your service. Users in ap-southeast-1 have a completely different path. Labeling one region's measurement 'global' hides every regional problem behind a number that describes nobody's experience.

## Edge cases

- probe locations inside your own cloud region measure cloud-internal paths, not internet paths
- traffic weighting needs real traffic shares; equal weighting misrepresents the user base
- synthetic checks do not capture last-mile variance; pair them with RUM for the full picture

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_HffeFGv0ymnzdgRmBKJ4rw