Cloudflare Traffic Control: Monitoring and Managing What Flows Through Your Edge

Cloudflare sits in front of your origin and touches every request your users make. Understanding what it’s doing with that traffic, what it blocks, what it caches, what it passes through, and what it costs you, is fundamental to running a reliable and secure edge. The native analytics give you a real and useful view of that. They also give you a partial one, and knowing where the picture ends matters as much as knowing how to read it.

This is a practical guide to Cloudflare traffic control: how traffic moves through the platform, the monitoring surfaces Cloudflare gives you and what each is actually for, the mechanisms you use to shape and block traffic, and the specific gaps teams run into once their setup grows past a single lightly-loaded zone. It’s written for people who are in the Cloudflare dashboard regularly and want to use it better and understand its edges.

How Traffic Flows Through Cloudflare

Everything downstream makes more sense once the path is clear. A request begins at DNS: Cloudflare resolves the hostname and directs the request to the nearest edge location. At that edge, the request runs through a sequence of layers before it ever reaches you. Security controls evaluate it first, IP access rules, then your custom WAF rules, then rate limiting, then Cloudflare’s managed rulesets, with any terminating action stopping the request there. If it survives security, the cache layer decides whether to serve a stored response or treat it as a miss. Only on a miss, or for uncacheable content, does the request finally travel to your origin.

Hold onto that order, because it’s the mental model for both control and monitoring. Every mechanism you configure acts at a specific point in this path, and every metric you read describes behavior at one of these stages. When traffic behaves unexpectedly, the question is almost always “which layer did this, and what was it configured to do?”

Cloudflare’s Native Traffic Monitoring Capabilities

Cloudflare gives you several distinct monitoring surfaces, and using them well starts with knowing what each one is for, because they overlap less than their names suggest.

Analytics Dashboard

The main analytics live under Analytics & Logs in the dashboard. The zone view covers HTTP traffic (requests, data transfer, page views, visits, and API requests), security (total threats, top crawlers and bots, rate limiting, and threats stopped), and performance (origin performance and bandwidth saved). This is your daily overview, and it’s genuinely good for spotting that something moved. Its main limit is resolution and depth, which are plan-gated. All customers get 30 days of data, but the time granularity varies sharply: Free customers can zoom to a one-hour scope over the last 24 hours, Pro and Business to a 15-minute scope over the last 6 hours, and Enterprise to a one-minute scope over the last 30 minutes. The dashboard tells you what happened. It’s less equipped to tell you why.

Security Events and Security Analytics

Here’s a distinction the dashboard makes that trips people up, and it’s worth getting right. Security Analytics shows all your incoming traffic, whether or not Cloudflare acted on it, while Security Events shows only the requests that Cloudflare’s security products acted on or flagged. That difference is the whole point of having both. When you’re investigating an anomaly, Security Events answers “what did my rules catch?” and Security Analytics answers the harder question, “what got through that maybe shouldn’t have?” The second view is where you find traffic that looks malicious but wasn’t mitigated, which is exactly the traffic that hurts you. Zone-level security analytics is available on all plans, though retention, query window, and filter options vary by plan, while account-level analytics requires Business or Enterprise.

Network Analytics

Network Analytics is a different tool for a different layer, and it’s frequently misunderstood as general traffic analytics. It provides near real-time visibility into network and transport-layer (L3/L4) traffic patterns and DDoS attacks, not HTTP request behavior. It’s also narrowly gated: the Network Analytics dashboard is only available to Enterprise customers using Spectrum, Magic Transit, or Bring Your Own IP. If you’re running standard HTTP traffic through Cloudflare, this isn’t the surface you’ll live in; it’s for teams protecting network-layer infrastructure.

Logpush

When the dashboards aren’t enough, raw logs are the answer, and Logpush is how you get them out. Logpush exports raw Cloudflare logs to a SIEM or storage backend, with datasets covering HTTP requests, firewall events, DNS logs, Spectrum events, audit logs, and more, delivered to destinations like R2, S3, Splunk, or any HTTPS endpoint. This is what unlocks deep analysis, long retention beyond the dashboard’s 30 days, and correlation with the rest of your security data. The catch is the gate: detailed logs and Logpush are an Enterprise-tier capability, so teams on lower plans work with the dashboard’s aggregated views and the GraphQL Analytics API rather than raw log streams.

Traffic Control Mechanisms in Cloudflare

Monitoring tells you what’s happening; these are the levers you pull to change it. Each acts at a specific point in the traffic path.

WAF Rules and Custom Rules

Custom rules are your primary tool for deciding what traffic is allowed, using Cloudflare’s Rules language to match on request properties and apply an action like Block, a challenge, Skip, or Log. The main discipline is ordering and scope: custom rules evaluate top to bottom, the first terminating match wins, and a rule scoped too broadly can short-circuit protections you meant to run later. Structure them from most specific to most general, and keep each rule narrow enough that you can predict what it catches.

Rate Limiting

Rate limiting shapes traffic by volume rather than pattern, counting requests against a threshold over a time window and acting when a client exceeds it. It’s the right tool for brute-force protection, API abuse, and scraping, where the problem is quantity rather than a signature. Because thresholds and counting dimensions have real subtlety, and because getting them wrong blocks real users, this deserves its own treatment; see our dedicated guide on configuring Cloudflare rate limiting rules for the threshold strategy.

IP Access Rules and Lists

IP Access rules operate at the front of the path, blocking, challenging, or allowing traffic by IP address, IP range, ASN, or country before other rules evaluate. They’re blunt and powerful, ideal for known-bad sources or geo-restrictions, and dangerous when stale. An allow entry for a contractor who left, or a country block added during one incident and never reviewed, is exactly the kind of thing that lingers. IP Lists let you manage these at scale and reuse them across rules rather than duplicating entries.

Cache Rules

Cache rules decide what gets cached, for how long, and under what conditions, which makes them a performance and a cost control at once. Caching aggressively where you safely can keeps traffic off your origin and your egress bill down; caching something dynamic by mistake serves one user’s content to another. The common failure is a broad cache-everything rule on a path that turned out to serve personalized responses, so treat cache changes as deliberate and watch the hit ratio after every one.

Workers and Transform Rules

For teams that need traffic manipulation beyond what rules express, Transform Rules rewrite request and response attributes like headers and URLs, and Workers run custom code at the edge for arbitrary logic. This is the most powerful tier of traffic control and the least observable from the standard dashboards, because the behavior lives in code and rewrites rather than in a rule table. Power here comes with a matching need for discipline: edge logic that isn’t documented becomes the thing nobody wants to touch.

What Cloudflare’s Dashboard Does Not Show You

The native tools are strong within their frame, and the frame has clear edges. Four gaps show up as teams scale.

The first is correlation between configuration changes and traffic anomalies. The dashboard shows your block rate spiked; it doesn’t show that a rule changed twelve minutes earlier and caused it. You can see the symptom and the change in two different places, but nothing joins them, so the connection is manual detective work every time. The second is cross-provider visibility, a unified view of every provider. The moment you run Akamai or Fastly alongside Cloudflare, the Cloudflare dashboard shows you exactly one third of your edge, and nothing native reconciles the three into one picture. The third is real-time cost attribution: the analytics show traffic volume and bandwidth, but not a live mapping of which configuration decision is driving which line on your bill, so cost surprises still arrive monthly. The fourth is historical configuration state, the ability to compare what your configuration was at the time of an incident against what it is now, which the audit log gestures at but doesn’t fully deliver.

For a single Cloudflare zone with light traffic, none of this may matter. For a complex or multi-vendor edge stack, these gaps are precisely where incidents hide and budgets leak, and closing them is the specific problem an edge observability layer like LELOPS SENTRY exists to solve, unifying traffic, configuration, and cost across every provider into one view.

Getting More From Cloudflare Traffic Control with LELOPS ADVISE

There’s a companion problem to visibility, and it’s about understanding rather than seeing. When a traffic pattern behaves unexpectedly, when you need to confirm that a rule is doing what you intended, or when you want to translate a desired behavior into the correct Cloudflare rule syntax, the answer usually lives across two places: the official Cloudflare documentation and your own live configuration. Bridging them by hand, reading the general docs and mapping them onto your specific setup, is where hours disappear.

This is what LELOPS ADVISE is built for. It connects Cloudflare’s official documentation to your live configuration, so instead of a generic reference result you get the exact answer for your setup. Ask in plain text why a specific rule is or isn’t behaving as expected, or how to express a behavior you want, and ADVISE grounds the answer in what you actually have deployed. It turns “the documentation says X, but what does that mean for my config?” into a direct answer, which is the gap between reference material and operational reality.

Need to understand what your Cloudflare configuration is actually doing? LELOPS ADVISE connects your live rules to the answers you need: lelops.ai/product/advise.

FAQ