--- title: "When Your CDN Blocks Your Monitoring" slug: "when-your-cdn-blocks-your-monitoring" updated: 2026-06-18T12:48:28Z published: 2026-06-18T12:48:28Z canonical: "docs.catchpoint.com/when-your-cdn-blocks-your-monitoring" --- > ## Documentation Index > Fetch the complete documentation index at: https://docs.catchpoint.com/llms.txt > Use this file to discover all available pages before exploring further. # When Your CDN Blocks Your Monitoring ### A Practical Guide to Resolution ![Image](https://cdn.document360.io/cb4af8f9-6751-4fd2-b39c-07aae832badb/Images/Documentation/image(629).png) ## At a Glance Catchpoint runs synthetic tests (HTTP, Browser, API, and Transactions) from real networks worldwide. Your CDN, WAF, or bot management platform may classify this traffic as automated and block it. When that happens, Catchpoint correctly reports a `403`, `429`, or challenge response. This is **not a false failure**. Your CDN is doing exactly what it was configured to do: blocking traffic it doesn't recognize. The fix lives in **your CDN/WAF policy**, not in Catchpoint. The goal is to create a **scoped exception** that allows monitoring traffic through without weakening your security posture. --- ## Why CDNs Block Synthetic Monitoring Modern CDN security platforms such as: - Cloudflare - Akamai - Fastly - Imperva - AWS CloudFront with AWS WAF use multiple detection mechanisms, including: - IP reputation - TLS fingerprinting - Request frequency analysis - Behavioral analysis - JavaScript challenges - Cookie presence validation - Bot classification models Synthetic monitoring traffic often triggers these controls because it is, by design, exactly what bot detection systems were built to detect. Synthetic tests typically: - Originate from fixed IP ranges - Run at a steady cadence - Repeatedly access the same endpoints - May not carry cookies or session history - Lack human behavioral signals Even a real Chrome browser running a scripted transaction can be flagged if its request pattern appears mechanical. > **Important:** This isn't a CDN bug. It's a classification problem. Your security platform correctly identifies non-human traffic but doesn't know this specific traffic belongs to you. --- ## Common CDN Controls That Block Synthetic Monitoring The table below maps common CDN security controls to their impact on Catchpoint tests. | Control Type | What It Does | Impact on Catchpoint Tests | | --- | --- | --- | | WAF Managed Rules | Blocks requests matching attack signatures or anomaly patterns | Scripted transactions or API requests may unintentionally trigger rules | | Bot Management | Classifies traffic as human, automated, verified bot, or unknown | Synthetic traffic may be challenged or blocked | | Rate Limiting | Blocks or throttles excessive requests | Multiple nodes or retries may exceed thresholds | | IP Reputation | Blocks traffic from networks with poor reputation scores | Monitoring nodes may require approval | | Geo or ASN Policies | Allows or blocks traffic by country, region, ASN, or provider | Tests may fail only in certain locations | | Header/Fingerprint Rules | Evaluates User-Agent, JA3/JA4, headers, cookies, and TLS signals | Browser, API, and transaction tests may behave differently | | JavaScript/CAPTCHA Challenges | Requires browser interaction or proof-of-work | API and HTTP tests cannot complete these challenges | | Firewall or ACL Policies | Blocks requests unless explicitly allowed | Tests require approved IPs, headers, or private paths | --- ## What You'll See When It Happens Catchpoint tests may report one or more of the following symptoms. ### HTTP 403 Forbidden The CDN rejected the request based on: - IP address - Headers - Bot classification rules ### HTTP 429 Too Many Requests A rate limiter was triggered because test frequency exceeded configured thresholds. ### JavaScript or Bot Challenge Page The CDN served a challenge instead of your application. Examples: - Cloudflare Turnstile - Akamai Bot Manager challenges Browser tests may render the challenge page. API tests typically receive challenge HTML in the response body. ### CAPTCHA or Interstitial Pages The CDN requires human interaction that synthetic tests cannot provide. ### Intermittent Geographic Failures Some CDN policies are regional or provider-specific. Example: - A test from Comcast in Chicago succeeds - The same test from Verizon in Dallas gets blocked > In every case, Catchpoint is reporting exactly what it received. The test reached the CDN, and the CDN denied access. --- ## How to Fix It The principle is simple: **Make your Catchpoint traffic identifiable and create a scoped exception.** Don't weaken your security. Make it smarter. ### Recommended Approaches (In Order of Preference) #### 1. Secret Header + IP Allowlist (Recommended) Configure Catchpoint to send a custom header on every request. Example: ``` X-Monitoring-Token: your-secret-value ``` Configure your CDN to allow requests only when: - The secret header is present - The request originates from approved Catchpoint IP addresses #### 2. IP Allowlist for Selected Catchpoint Nodes If custom headers aren't feasible: - Allowlist only the Catchpoint node IPs being used - Restrict access to specific hosts and paths #### 3. Create a Scoped CDN/WAF Rule Build rules using: - Host - Path - HTTP Method - User-Agent - Source IP Example: ``` Allow GET /api/health FROM Catchpoint IPs WITH User-Agent containing "Catchpoint" ``` #### 4. Adjust Rate Limits If rate limiting is the issue: - Increase thresholds only for monitored endpoints - Exclude monitoring IPs from rate calculations Do not increase global rate limits. --- ## What Not To Do - ❌ Don't allowlist by User-Agent alone - ❌ Don't create broad exceptions - ❌ Don't disable Bot Management or WAF protections - ❌ Don't share secret headers publicly --- ## What Catchpoint Provides for CDN Investigations ### Test Details - Test name - Test type (HTTP, Browser, Transaction, API) - Test ID - Target URL - Host - Path - HTTP method ### Source Node Details - Node name - City - Network provider - IP address ### Request Evidence - Request headers - User-Agent - Custom headers - Cookies ### Response Evidence - HTTP status code - Response headers - CDN request IDs - Debug headers - Response body snippets ### HAR Files and Waterfalls For Browser and Transaction tests, Catchpoint can provide the full request/response sequence. ### Failure Scope Analysis Determine whether the issue affects: - All nodes - Specific geographies - Specific network providers --- ## The Conversation to Have With Your CDN Team ### This Is Your Monitoring, Not an Attack The traffic: - Comes from known IPs - Runs at a known cadence - Tests known endpoints Think of it as your own security guard checking the locks. ### The Goal Is Identification, Not Exemption You are not bypassing security. You are teaching your security platform to recognize traffic that belongs to you. ### Catchpoint Makes Identification Easy Catchpoint provides: - Fixed IPs - Custom headers - Documented User-Agents - Predictable request patterns ### The Fastest Resolution The quickest path to resolution is typically a three-way discussion between: 1. Customer Application Team 2. Customer CDN/Security Team 3. Catchpoint **Fifteen minutes with the right people in the room usually solves the issue.**