Multi-region monitoring

Multi-region monitoring means we probe your site from more than one geographic location at the same time. A single probe in Frankfurt won't catch a regional outage on a US-only CDN edge. And paging the on-call at 3 AM because a single edge server hiccuped is the fastest way to train your team to ignore alerts.

How it works on Everguardly

Each monitor opts into one or more regions via its Check from regions setting. V1 ships three regions: EU Central (Frankfurt), US East (Virginia), and Asia Southeast (Singapore).

Each region's worker runs scheduled HTTP probes on the same monitor independently and tags every result row with the region it came from. The dashboard then groups by region. Pick 2 regions to cut false positives, or 3 for global-spread agencies (e.g. you've got clients in EU + AU and want APAC probe latency).

Regional vs global incidents

When at least one region reports a failure, Everguardly opens an incident. The incident's scope follows the failing set:

• Regional — one of N probing regions failing. Likely a single-edge hiccup; yellow indicator + lower-urgency copy.
• Global — every probing region failing. Real outage; red indicator + full "DOWN" alert.

A regional incident:

• Carries a yellow indicator on the status page, not a red one.
• Renders as "regional issue" in alerts, not "DOWN".
• Includes Down in: US East copy so the on-call knows where to look.

If a regional incident escalates (the other region starts failing too), Everguardly updates the same incident in place rather than opening a new one — the alert thread stays a single story per outage. Conversely, a global incident that recovers in one region drops back to regional.

False-positive reduction in practice

The math is straight-forward: if your monitor has 99.9% per-region uptime and a single region throws a false negative once a month, a single probe-per-monitor setup pages you 12 times a year for non-issues. With 2-region probing the "both regions disagree" filter cuts that to once every couple of decades.

The trade-off is the SSL + domain probes run once per region too, which means slightly more outbound traffic from your sites; for HTTP/HTTPS endpoints that's negligible (we cap at 1 request per region per check interval).

Per-monitor configuration

Open the monitor's edit dialog and check the regions you want to probe from under Check from regions. You can change this at any time.

• Newly-added regions start producing data as soon as that region's worker hits its next scheduler tick (within 30 seconds for HTTP).
• Removed regions stop probing immediately; their historical rows stay in place so the detail page can still surface "last seen up in US East 3 days ago" if you re-add a region later.

What to expect on the dashboard

The monitor detail page (/dashboard/monitors/[id]) gains a per-region status strip. Each region card shows:

• Latest probe result (Up / Down / Pending)
• Average latency over the last 24 hours
• Up-percentage over the last 24 hours
• "x minutes ago" for the last probe

Setup Day deployment

In V1's local-dev environment everything runs from a single worker process defaulting to EU Central. Setup Day's Railway deployment provisions three worker instances: WORKER_REGION=eu-central (Europe West / Amsterdam-Frankfurt), WORKER_REGION=us-east (US East / Virginia), and WORKER_REGION=asia-southeast (Asia Southeast / Singapore) — same Postgres + Redis behind all three. Workers don't talk to each other; each region's scheduler only picks up monitors whose region_affinity array contains its own region. Cost delta for the third worker is ~$1-2/mo above Railway's $5 free tier covering EU + US.

Coming in V2

• Geographic affinity — "probe from the region closest to the customer's audience".
• Region-specific alert routing — "only page the EU team when EU fails".
• Trusted regions — enterprise customers run a worker inside their own VPC.