Whitelisting Telescope in Your Firewall

If your HTTP monitor shows as degraded instead of up, or your agentic (browser) monitor is failing, your firewall is likely blocking Telescope's monitoring requests. This guide covers how to allow them through.

Telescope's IP addresses

Telescope checks originate from two sets of IP addresses, depending on the monitor type. Whitelist both sets if you use both kinds of monitors.

Standard checks

Every monitor type except agentic — HTTP, keyword, SSL, domain, ping, TCP port, DNS, mail, PageSpeed, and similar — originates from these twelve static IP addresses (three per region):

Whitelist all twelve — your site is checked from the nearest region, but failover may route checks through any region, and each region uses any of its three IPs.

Browser (agentic) checks

Agentic monitors drive a real browser and do not use the standard IPs above. They reach your site from one or more dedicated egress IPs shown live in your Telescope portal:

1. In the portal, go to Team settings.
2. Find the Monitoring egress IP card and copy every IP address listed (use Copy all if there is more than one).
3. Add each one to the same allow rules as the standard IPs.

Always use the values shown in your portal — they are the authoritative current IPs for browser checks. If agentic monitors that previously passed start being blocked, re-check the portal values and update your firewall rules.

Cloudflare

IP Access Rules (recommended)

1. Log in to the Cloudflare dashboard and select your site.
2. Go to Security > WAF > Tools.
3. Under IP Access Rules, add each Telescope IP address:
   • Set Value to the IP address.
   • Set Action to Allow.
   • Set Zone to your site.
4. Repeat for all twelve standard IPs, plus every browser-check egress IP if you use agentic monitors.

Alternatively, use a WAF Custom Rule:

1. Go to Security > WAF > Custom rules.
2. Click Create rule.
3. Set the rule name to Allow Telescope Monitoring.
4. Set the expression to:

(ip.src in {152.55.180.240 152.55.180.241 162.220.234.242 152.55.176.240 162.220.232.250 162.220.232.251 152.55.184.241 208.77.244.240 208.77.244.242 208.77.246.240 208.77.246.241 208.77.246.242})

If you use agentic monitors, append or (ip.src eq <browser-check egress IP>) for each IP listed under Team settings > Monitoring egress IP.

5. Set the action to Skip and check all remaining custom rules.
6. Click Deploy.

Bot Fight Mode / I'm Under Attack Mode

If you have Cloudflare's Bot Fight Mode enabled, the IP allow rules above should take priority. If checks are still being blocked:

1. Go to Security > Bots.
2. Under Configure Super Bot Fight Mode, ensure "Definitely automated" is set to Allow or verify the IP allow rules have higher priority.

Sucuri

1. Log in to the Sucuri dashboard.
2. Go to Settings > Security.
3. Under Whitelisting, click Add.
4. Add each Telescope IP address to the whitelist — the twelve standard IPs, plus every browser-check egress IP if you use agentic monitors.
5. Save your changes.

If using the Sucuri WordPress plugin:

1. Go to Sucuri Security > Firewall (WAF) in your WordPress admin.
2. Navigate to Settings > Access Control > IP Address.
3. Add the same Telescope IP addresses to the whitelist.

AWS WAF

1. Open the AWS WAF console.
2. Create an IP set named TelescopeMonitoring containing:
   • 152.55.180.240/32
   • 152.55.180.241/32
   • 162.220.234.242/32
   • 152.55.176.240/32
   • 162.220.232.250/32
   • 162.220.232.251/32
   • 152.55.184.241/32
   • 208.77.244.240/32
   • 208.77.244.242/32
   • 208.77.246.240/32
   • 208.77.246.241/32
   • 208.77.246.242/32
   • Each browser-check egress IP as a /32, if you use agentic monitors.
3. Select your Web ACL.
4. Go to Rules and click Add rules > Add my own rules.
5. Choose Rule builder.
6. Set rule name to AllowTelescopeMonitoring.
7. Under Statement:
   • Inspect: Originates from an IP address in
   • IP set: Select TelescopeMonitoring
8. Set the action to Allow.
9. Set the rule priority so it evaluates before any block rules.
10. Click Add rule and Save.

Akamai

1. Open the Akamai Control Center.
2. Navigate to Security > Web Application Firewall.
3. Select your security policy.
4. Go to Exceptions or Bypass rules.
5. Create a new exception:
   • Condition: Client IP is in the twelve standard IPs from the table above, plus every browser-check egress IP if you use agentic monitors
   • Action: Bypass WAF inspection
6. Save and activate.

Wordfence (WordPress)

1. In your WordPress admin, go to Wordfence > Firewall > Blocking.
2. Go to the Whitelisting tab (or Allowlisted IPs).
3. Add all twelve standard Telescope IP addresses:
   • 152.55.180.240
   • 152.55.180.241
   • 162.220.234.242
   • 152.55.176.240
   • 162.220.232.250
   • 162.220.232.251
   • 152.55.184.241
   • 208.77.244.240
   • 208.77.244.242
   • 208.77.246.240
   • 208.77.246.241
   • 208.77.246.242
4. If you use agentic monitors, also add every browser-check egress IP from Team settings > Monitoring egress IP.

Generic / Other Firewalls

For any firewall not listed above, create allow rules for these IP addresses:

All twelve standard IPs must be whitelisted — your site will be checked from the nearest region, but failover may route checks through any region, and each region uses any of its three IPs. Agentic checks only ever come from the browser-check egress IPs listed in your portal.

Most firewalls support IP-based allow rules. Check your provider's documentation for "whitelist", "allow list", or "bypass" rule configuration.

Verifying it works

After adding the whitelist rules:

1. Wait for the next check cycle (based on your monitor's frequency).
2. Your monitor should transition from degraded to up.
3. If the monitor is still degraded after a few cycles, double-check that every Telescope IP is whitelisted and the rules are active with higher priority than any block rules.

Still experiencing issues?

If a standard monitor is still showing as degraded after whitelisting the twelve standard IP addresses, additionally whitelist Telescope's User-Agent header:

User-Agent: Telescope-Uptime/2.0

Some firewalls apply multiple layers of filtering, and adding the User-Agent to your allow rules ensures requests aren't caught by bot detection or rate limiting rules that operate independently of IP-based rules.

This User-Agent applies to standard checks only. Agentic checks run a real browser with a normal browser User-Agent, so they can't be identified by a fixed User-Agent string — rely on the IP allow rules for the browser-check egress IPs instead.

Troubleshooting

Monitor still shows degraded after whitelisting

• Ensure every relevant IP address is whitelisted — standard checks can originate from any of the twelve IPs across the four regions, and agentic checks use the separate browser-check egress IPs.
• Ensure the rules are deployed/active (some firewalls require manual activation).
• Check the rule priority — block rules evaluated first will still fire before your allow rule.

Agentic monitor blocked, standard monitors fine

• The browser-check egress IPs are separate from the standard IPs and must be whitelisted on their own. Copy the current values from Team settings > Monitoring egress IP in your portal and make sure every listed IP is in your allow rules.

Monitor shows down, not degraded

• This means the site is actually unreachable or returning an error. The issue is not firewall-related. Check your server logs.

Rate limiting (429 responses)

• If your firewall rate-limits requests, Telescope sends one check per frequency interval (minimum 30 seconds). This should be well within any reasonable rate limit. If you're still hitting 429s, increase the per-IP rate limit for Telescope's IP addresses.