---
title: "Public probes | Grafana Cloud documentation"
description: "Find Synthetic Monitoring public probe locations and cloud providers, review k6 compatibility and memory limits, and investigate checks blocked by endpoint security rules."
---

> For a curated documentation index, see [llms.txt](/llms.txt). For the complete documentation index, see [llms-full.txt](/llms-full.txt).

# Public probes

Public probes are [probes](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/introduction/#probes) operated by Grafana Labs in distributed locations around the world. They run tests against your targets and report the results to Grafana Cloud.

Running tests from different regions can reveal performance and availability issues that are specific to a location. You can choose from public probes in AMER, EMEA, and APAC.

You can also set up [Private probes](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/set-up/set-up-private-probes/) in Synthetic Monitoring.

If you need to allow access through your firewall, refer to [source IP addresses for allow-listing](https://grafana.com/docs/grafana-cloud/account-management/allow-list/).

## Public probe locations

You can find a list of public probes and your private probes by going to **Testing & synthetics > Synthetics > Probes**.

The following tables list public probe locations, countries, and cloud providers by region.

### The Americas (AMER)

Expand table

| Location         | Country | Cloud Provider |
|------------------|---------|----------------|
| Calgary          | CA      | AWS            |
| Montreal         | CA      | AWS            |
| North California | US      | AWS            |
| North Virginia   | US      | AWS            |
| Ohio             | US      | AWS            |
| Oregon           | US      | AWS            |
| São Paulo        | BR      | AWS            |

### Europe, Middle East, Africa (EMEA)

Expand table

| Location  | Country | Cloud Provider |
|-----------|---------|----------------|
| Cape Town | ZA      | AWS            |
| Frankfurt | DE      | AWS            |
| London    | UK      | AWS            |
| Paris     | FR      | AWS            |
| Spain     | ES      | AWS            |
| Stockholm | SE      | AWS            |
| UAE       | AE      | AWS            |
| Zurich    | CH      | AWS            |

### Asia-Pacific (APAC)

Expand table

| Location  | Country | Cloud Provider |
|-----------|---------|----------------|
| Hyderabad | IN      | AWS            |
| Jakarta   | ID      | AWS            |
| Mumbai    | IN      | AWS            |
| Seoul     | KR      | AWS            |
| Singapore | SG      | AWS            |
| Sydney    | AU      | AWS            |
| Tokyo     | JP      | AWS            |

## Compatibility and limitations for k6 checks

Scripted checks and browser checks have specific limitations when it comes to public probes:

- For how to view the k6 channels each probe supports, refer to [Probe compatibility](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/create-checks/manage-k6-versions/#probe-compatibility).
- For public probe memory limits, refer to [k6 browser check limitations](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/create-checks/checks/k6-browser/#public-probe-memory).

## Checks blocked by target security rules

A web application firewall (WAF), content delivery network (CDN), or CAPTCHA challenge can block requests from public probes. A check can fail from one or a few probe locations while succeeding from others because those locations reach the target from different source IP addresses.

To investigate whether security rules are blocking a check:

1. Identify the affected probes and inspect their execution logs. Refer to [Visualize check execution](https://grafana.com/docs/grafana-cloud/observe-and-act/testing/synthetic-monitoring/analyze-results/visualize-check-execution/).
2. Compare failed and successful executions for the same period. A location-specific failure is a reason to investigate access rules, but it doesn’t establish that a rule caused the failure.
3. Check your target’s firewall, WAF, or CDN logs for requests from the affected probe locations. Look for a rule that denies the request or requires an interactive challenge.
4. If a rule blocks the check, work with the owner of that rule to allow the monitoring traffic. Use the current [Synthetic Monitoring source IP ranges](https://grafana.com/docs/grafana-cloud/platform/security-and-account-management/security-and-access/allow-list/#synthetic-monitoring) to identify public probe traffic. Keep the allowlist current as probe IP addresses change.

An interactive challenge prevents the check from testing the intended response or journey. Configure access for monitoring traffic rather than trying to solve the challenge in the check script.