Articles

Read Cloudflare Analytics to Understand Traffic and Threats (2026)

April 16, 2026 6 min read

Cloudflare Analytics can tell you far more about your traffic than just hit counts; it’s a real-time window into what’s hitting your servers, and critically, what’s being stopped.

Let’s look at a typical request flow and how Cloudflare’s edge network processes it, then how that data surfaces in Analytics.

Imagine a user in London wants to access your website, example.com.

  1. DNS Resolution: The user’s browser asks a DNS resolver (e.g., Google’s 8.8.8.8) for example.com’s IP address. The resolver queries Cloudflare’s authoritative DNS servers. Cloudflare responds with the IP address of its nearest edge location in London.
  2. HTTP(S) Request: The user’s browser connects to the London edge IP and sends an HTTP(S) request for example.com.
  3. Security Inspection: Cloudflare’s edge server inspects the request. This is where the magic happens:
    • WAF (Web Application Firewall): Checks for common attack patterns (SQL injection, XSS, etc.).
    • Rate Limiting: Verifies if the client is exceeding configured request limits.
    • Bot Management: Identifies and challenges suspicious automated traffic.
    • IP Reputation: Checks the source IP against known malicious IP lists.
    • Managed Rulesets: Applies pre-configured security rules.
  4. Caching: If the requested resource is in the London edge cache and still fresh, Cloudflare serves it directly, bypassing your origin server.
  5. Origin Fetch (if needed): If not cached or expired, the edge server forwards the request to your origin server.
  6. Response: Your origin server processes the request and sends the response back to the Cloudflare edge.
  7. Edge Processing & Delivery: The Cloudflare edge receives the response, caches it if applicable, and sends it back to the user in London.

This entire process, from the edge receiving the request to sending the response, is logged and aggregated. Cloudflare Analytics provides a dashboard view of these logs.

Here’s a simplified representation of a request and its Cloudflare metadata:

{
  "timestamp": "2023-10-27T10:30:00Z",
  "client_ip": "192.0.2.10",
  "colo": "LHR",
  "request": {
    "method": "GET",
    "host": "example.com",
    "uri": "/blog/latest-post",
    "protocol": "HTTP/2"
  },
  "response": {
    "status": 200,
    "bytes": 5120,
    "cache_status": "HIT"
  },
  "security": {
    "managed_challenge": "none",
    "firewall_rule_id": null,
    "bot_score": 0.1,
    "threat_score": 0
  },
  "Ray": "a1b2c3d4e5f6g7h8-LHR"
}
  • client_ip: The actual IP of the visitor.
  • colo: The Cloudflare data center (LHR for London Heathrow).
  • cache_status: HIT means Cloudflare served from cache, MISS means it went to origin.
  • managed_challenge: If Cloudflare presented a "This page is protected" challenge.
  • threat_score: A numerical score indicating how likely the request is malicious.

Now, let’s dive into what you can see and do with this data.

Understanding Traffic Sources and Patterns

The "Traffic" tab in Cloudflare Analytics is your starting point.

  • Requests Over Time: This graph shows your total requests, broken down by HTTP Method, Content Type, and Country. If you see a sudden spike in POST requests from a single country, that’s worth investigating. Is it legitimate user activity, or a bot trying to brute-force a login form?
  • Bandwidth: Similar to requests, but shows data transferred. A spike here could indicate large file downloads or, again, bot activity.
  • Unique Visitors: Helps understand your actual user base versus automated traffic.

Identifying and Mitigating Threats

The "Security" tab is crucial. This is where Cloudflare’s edge security features report their actions.

  • Overview: This provides a summary of blocked requests, WAF challenges, bot management actions, and requests that triggered rate limits.
  • Firewall Events: This is the most granular view. You can filter by Action (Block, Challenge, Log), Rule ID (which WAF rule triggered), Threat Score, and Client IP.

Let’s say you see a persistent stream of WAF Block events with a Rule ID like 100001 (a common Cloudflare managed rule for SQL injection).

Diagnosis: You’d go to the "Security" -> "WAF" -> "Firewall Events" section in your Cloudflare dashboard. Filter by Action: Block and Rule ID: 100001. Look at the Client IP column. If you see the same IPs repeatedly, or a large number of IPs hitting the same URL pattern (e.g., /wp-admin/admin-ajax.php?action=...), it’s a clear indicator of an attempted SQL injection attack.

Fix:

  1. If the attack is widespread and generic: Ensure your WAF Managed Rulesets are enabled and updated. Cloudflare usually handles this.
  2. If specific IPs are causing it: You can add a custom firewall rule. Go to "Security" -> "WAF" -> "Firewall Rules". Click "Create Rule".
    • Rule Name: Block SQLi Bots
    • Field: IP Source Address
    • Operator: is in
    • Value: Enter the offending IP addresses (e.g., 192.0.2.50, 192.0.2.51).
    • Action: Block
    • Click "Deploy". This rule will prevent any further requests from those specific IPs.
  3. If it’s targeting a specific vulnerability: Review your application code for that vulnerability. If it’s a known CVE, ensure your WAF has the appropriate rules enabled or consider updating your application.

Why it works: The WAF rule 100001 is designed to detect patterns indicative of SQL injection attempts. By blocking requests matching this pattern from specific IPs, you prevent malicious payloads from reaching your origin server. Custom rules allow you to enforce stricter measures on known bad actors.

Bot Management Insights

The "Security" -> "Bots" section is invaluable. It shows traffic categorized as "Automated," "Challenged," and "Likely Automated."

Diagnosis: If "Automated" traffic is high, especially for sensitive endpoints (like API endpoints or login pages), it suggests bots are actively probing your site. Look at the "Threat Score" and "Bot Score" associated with these requests in Firewall Events. High threat scores combined with "Automated" classification point to malicious bots.

Fix:

  1. Enable Bot Fight Mode: Go to "Security" -> "Bots" and toggle "Bot Fight Mode" to "On". This automatically applies JavaScript challenges to suspicious bots.
  2. Configure Bot Management: For more advanced control, use "Security" -> "Bots" -> "Bot Management". You can create rules to challenge or block traffic based on bot score, threat score, or specific user-agent strings. For example, a rule to Challenge any request with a Bot Score greater than 30 and Threat Score greater than 10.
  3. Rate Limiting: Implement rate limiting on critical endpoints. Go to "Security" -> "WAF" -> "Rate Limiting Rules". Create a rule like:
    • Rule Name: Login Page Rate Limit
    • If Traffic Matching: URI Path equals /login
    • Then: Block requests from a IP Address that made more than 100 requests in 5 minutes. This prevents brute-force attacks.

Why it works: Bot Fight Mode and Bot Management use sophisticated JavaScript challenges and behavioral analysis to distinguish bots from humans. Rate limiting provides a hard ceiling on request volume from any single source, preventing overwhelming your server or guessing credentials.

The one thing most people don’t know is that the Ray ID in the request logs isn’t just a unique identifier; it’s a trace. If you ever need to debug a specific request that made it to your origin, and you have access to your origin server logs, you can correlate the Ray ID. This allows you to see exactly what Cloudflare saw, what rules it applied, and then what your origin server did with that request, bridging the gap between edge and origin troubleshooting.

The next thing you’ll likely encounter is understanding how to leverage the API to automate these security and traffic management tasks.

Want structured learning?

Take the full Cloudflare course →