Skip to main content

Understanding UptimeRobot Locations and Multi-Location Feature

Understand how UptimeRobot uses multiple locations to check your website uptime for accurate monitoring and fewer false alerts.

Updated over a week ago

How UptimeRobot Monitoring Works

UptimeRobot performs monitoring checks from various locations around the world, ensuring comprehensive and reliable uptime monitoring of your services. Here's a detailed explanation of how our monitoring process works:

  1. Randomized Checks:

    • UptimeRobot conducts checks from a pool of various IP addresses from the selected region.

    • For every monitoring check, we randomly select three different checker nodes.

    • If all three checks from these random nodes fail, an incident is reported.

  2. Incident Reporting:

    • The IP addresses listed in the incident report are the ones that detected the downtime.

    • It’s important to note that the reported IP in a resolved incident is from the downtime period and does not reflect the node/IP that confirmed the service is back online.

    • To minimize false positives, users should ensure that the IPs listed in the incident reports are whitelisted, even if they don't whitelist all the IPs from our comprehensive list.

  3. IP Whitelisting:

    • Ideally, users should whitelist all IPs from our provided list to ensure consistent and accurate monitoring.

    • Even if only some IPs are whitelisted, it is crucial to whitelist the IPs mentioned in the incident reports.

    • Check the list of UptimeRobot monitoring IP addresses here: UptimeRobot Monitoring IPs.

  4. Behavior with Partial Whitelisting:

    • If some but not all IPs are whitelisted, there may be inconsistencies in monitoring results.

    • For instance, if 10 IPs are whitelisted and 10 are not, the monitoring might show the service as “UP” if one of the whitelisted IPs gets selected. However, this is not the desired behavior as it can lead to inaccurate reporting.

    • Conversely, if a check involves non-whitelisted IPs, it might incorrectly report a downtime.

Multi-Location Feature for Paid Plans

For users on paid plans, UptimeRobot offers the ability to specify monitoring from particular geographical regions. This feature helps tailor the monitoring experience based on target user locations.

​Multi-location monitoring checks your services from multiple geographic regions in rotation, so that you know whether an issue is local to one data center or affecting users worldwide.

With multi-location monitoring, you can:

  • Monitor from up to four regions: North America, Europe, Asia, and Australia

  • Set per-region response time thresholds: because acceptable latency in North America may differ from Asia

  • See per-region status at a glance: a visual map shows the status of each configured region

  • Get smarter incident detection: the system identifies exactly which regions are affected and only marks the monitor as resolved when all regions recover

  • View response time data filtered by region: isolate performance issues to specific geographies

Available Regions:

  • Default (We randomly select the NA or EU region for you, but we can change the region at any time).

  • North America.

  • Europe

  • Asia

  • Australia.

How It Works

Setting Up Regions

  1. Go to Monitors and create a new monitor (or edit an existing one).

  2. Find the Region to monitor from field.

  3. Select multiple regions by clicking the + button to add more. You can choose any combination of available regions.

  4. Save the monitor.

Configure regions of your UptimeRobot monitor

Tip: If you're unsure which regions to choose, start with the regions where most of your users are located. You can always add or remove regions later.

Bulk Region Updates

You can update the monitoring regions for multiple monitors at once:

  1. Go to Monitors and select the monitors you want to update.

  2. Choose the bulk region update option.

  3. Select the new region configuration.

Bulk update regions of monitors in your UptimeRobot account

Free plan users can select one region in bulk updates. Paid plan users can select multiple regions.

How Incidents Work with Multiple Regions

When monitoring from multiple regions, incidents provide more detail about where the problem is:

  • Down detection: When any single region fails three consecutive checks, the monitor is marked as Down and a down notification is sent.

  • Regional tracking: If additional regions also go down after the initial incident, they're tracked as part of the same incident, so you can see exactly which regions were affected in the activity log.

  • Recovery: The monitor returns to Up status and a recovery notification is sent when all regions have recovered. If one region recovers but another is still failing, the monitor stays Down.

This means you can tell from the incident details whether an issue was isolated to one region (like a CDN edge node going down in Europe) or a widespread outage affecting multiple regions.

Response Time Monitoring by Region

Filtering the Response Time Chart

The response time chart on the monitor detail page includes a region dropdown so you can view performance data for each region individually. Select a region from the dropdown to see response times specific to that location. Your selection is saved and persists across browser sessions.

An All regions option is always available, which combines response time data from all regions into a single view.

Per-Region Response Time Thresholds

If you're monitoring from multiple regions, you can set a different response time threshold for each region. This is useful when your service naturally responds faster in regions closer to your servers.

To configure per-region thresholds:

  1. Open the monitor's settings.

  2. Click the response time alert configuration.

  3. When multiple regions are configured, you'll see a separate Response time alert threshold input for each region.

  4. Set the threshold (in milliseconds) for each region independently.

When a region's response time exceeds its threshold, a slow response time incident is created for that specific region. Each region's slow response time alerts are tracked and resolved independently.

API Access

Multi-location monitoring is fully supported through the public API v3.

Creating a Monitor with Multiple Regions

curl -X POST https://api.uptimerobot.com/v3/monitors \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"friendlyName": "My Global Service",
"url": "https://example.com",
"type": "HTTP",
"interval": 300,
"regionData": {
"REGION": ["na", "eu", "as"]
}
}'

Setting Per-Region Response Time Thresholds

curl -X PATCH https://api.uptimerobot.com/v3/monitors/12345 \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"regionData": {
"REGION": ["na", "eu", "as"],
"THRESHOLD": {
"na": 2000,
"eu": 3000,
"as": 5000
}
}
}'

Getting Response Time Statistics by Region

curl -X GET "https://api.uptimerobot.com/v3/monitors/12345/stats/response-time/all?includeTimeSeries=true" \
-H "Authorization: Bearer YOUR_API_KEY" \
-H "Content-Type: application/json"

This returns response time statistics broken down by region (na, eu, as, oc) plus an all aggregate.

Available region codes: na (North America), eu (Europe), as (Asia), oc (Australia).

Note: The older regionalData field (which accepts a single region code string) is deprecated. Use the regionData field with the REGION array for new integrations.

Troubleshooting False Positives

False positive up/down notifications can occur when monitoring service requests are blocked by security layers such as firewalls, WAFs, or CDNs. To resolve these issues, follow these steps:

  1. Identify the Security Layer Blocking Requests

    • Determine whether the issue originates from your server firewall, WAF/CDN, or hosting provider's security rules.

  2. Allowlist Monitoring Service IP Addresses

    • Obtain the list of IP addresses used by your monitoring service.

    • Add these IP addresses to the allowlist or permit rules for HTTP/HTTPS traffic to your monitored endpoints.

  3. Ensure Accessibility for Keyword Monitoring

    • If you use keyword monitoring, ensure the monitored page is accessible to the monitoring service probes.

    • The page should serve the expected keyword without requiring authentication or triggering bot-blocking mechanisms.

  4. Apply and Save the Rules

    • Save the updated allowlist rules and apply them to your security systems.

    • Allow some time for the changes to propagate.

  5. Monitor for Stability

    • Observe your monitoring alerts to ensure the issue is resolved. If false positives persist, recheck your configurations. By following these steps, you can minimize false positive notifications and ensure accurate monitoring of your servers and websites.

Did this answer your question?