A while back, we noticed a suggestion on our feedback page that some of you pointed out: While our Cloudflare add-on did wonders for your website’s performance and security, it lacked any insight into the exact usage of Cloudflare’s cache as well as the benefits of each security feature.
To further validate this request, we reached out to a few of you using the add-on extensively across multiple sites.
Turns out, even though the Cloudflare add-on was functioning well behind the scenes & protecting your sites from any harm, the lack of any value indicator restricted you from determining the exact outcome of adding Cloudflare. This was a real pain point, especially for those using it for clients.
Taking your feedback to heart, we went back to the drawing board and came up with a solution to resolve this issue. Your feedback told us exactly what you wanted! Insights into various cache & security events along with their sources. Similar to that offered by Cloudflare directly.
Our Solution: Cache & Security Analytics
And with that, we’re delighted to announce the addition of cache & security analytics to the Cloudflare Enterprise add-on, letting you easily see the number of requests being served by Cloudflare vs Origin, as well as a breakdown of each request’s status along with their sources.
Similarly, it’ll let you track the amount of malicious traffic blocked and the potentially malicious actors challenged by the add-on with a breakdown of specific services, blocking these and their sources.
At the moment, you can view data for the last 72 hours. Rest assured, we’re working hard behind the scenes to enhance this capability further.
What Is Cache Analytics in Cloudflare?
Our cache analytics implementation provides simple insights into your website’s performance with just two main variables. requests (by number) and data transfer.
Each of these is broken down into an overall summary, cache statuses, and sources.
The summary of requests provides insights into the total number of requests, with a breakdown of those served by Cloudflare and those served by origin. This helps you determine if there’s a need to reduce the load on the origin and troubleshoot any issues causing excess load.
And if you’re interested in data transfer, this report lets you see the exact amount of data served by Cloudflare vs origin, thus allowing you to determine exactly how much bandwidth each is consuming.
2. Cache Status
The cache status section provides a breakdown of the cache status of each request, providing insights into how Cloudflare handles them. This includes the number of requests being served from Cloudflare’s cache (HIT), those not cached at Cloudflare’s edge (MISS), and requests that cannot be served by Cloudflare due to their ineligibility for caching or as a result of Cloudflare’s WAF (NONE & DYNAMIC).
Switching over to data transfer, you can see the exact bandwidth used up by these requests, thus allowing you to determine any potential issues.
Here’s a description of each status and why it’s shown:
|The resource was found in Cloudflare’s cache.
|The resource was not found in Cloudflare’s cache and was served from the origin web server.
|Cloudflare typically considers assets like HTML pages as ineligible for caching, resulting in a DYNAMIC status.
However, if you enable options like edge page caching (limited to WordPress), Cloudflare will start caching HTML pages and will return HIT or MISS based on the HTML resource available in Cloudflare Cache.
|Cloudflare may generate a response indicating that the asset is ineligible for caching due to certain reasons:
1) If a WAF custom rule is triggered to block a request, the response will be served from the Cloudflare global network before it hits the cache. Since there is no cache status, Cloudflare will log as none/unknown.
2) If a redirect cache rule causes the global network to respond with a redirect to another asset/URL. This redirect response occurs before the request reaches the cache, so the cache status is logged as none/unknown.
|The resource was found in Cloudflare’s cache but had expired and was served from the origin web server.
|The resource was served from Cloudflare’s cache but expired, and Cloudflare could not contact the origin to retrieve an updated resource.
|Cloudflare generated a response denoting that the asset is bypassed from caching. This could occur due to the following reasons:
The origin server instructed Cloudflare to bypass caching via a Cache-Control header set to values such as no-cache, private, or max-age=0, despite Cloudflare’s preference to cache the asset.
Once Edge Page Caching (Limited to WordPress) is enabled, certain URLs and cookies are excluded from the cache, resulting in BYPASS
If the request to your origin includes an Authorization header, in some cases, the response will also be BYPASS. You can refer to Conditions in the Origin Cache-Control behavior section for more details.
|The resource is served from Cloudflare’s cache but is stale and was revalidated by either an If-Modified-Since header or an If-None-Match header.
|The resource was served from Cloudflare’s cache and expired, but the origin web server is updating it. UPDATING is typically only seen for very popular cached resources.
The Source section provides detailed insights into various aspects of each event, including the exact content types, paths, hosts, devices, and countries of origin. This allows you to determine your most popular content types and understand your audience’s demographics, including their devices and countries.
Sorting this information by data transfer allows you to identify which content types & pages are consuming the most bandwidth.
Additionally, you can view the most frequent edge status codes, which range between 1xx Informational, 2xx Success, 3xx Redirect, 4xx Client Error, and 5xx Server Error, providing additional insights into any potential issues & problems.
Detailed Security Analytics in Cloudflare
The security analytics tab provides a deeper understanding of the number of malicious actors stopped or managed by our Cloudflare add-on. Similar to cache analytics, it’s broken down into an Events Summary, a breakdown of events by services (where services refer to the type of security measure) & events by source, helping you determine which IP addresses, user agents, paths & countries these malicious requests originated from.
1) Events Summary
The events summary tab showcases the total number of potentially malicious actors attempting to access your website. Requests identified as malicious are blocked outright, while those from potentially malicious bots are challenged to verify their human identity.
Any sudden spikes on the graph below indicate the possibility of a targeted DDoS attack on your website. This helps you stay alert & take any additional security measures, such as activating the “Under Attack” mode.
2) Events by Services
The events by services section breaks down the number of security events triggered & managed by each service.
Whether it’s global rate limiting to fend off bots, custom rules set by Cloudways, or HTTP DDoS attacks, allowing you to determine the types of malicious actors attempting to access your site.
Depending on the type of malicious actor, it may be triggered & managed by various services, including:
- Rate limiting rules: These detect and restrict bot traffic to prevent overload on your site.
- Security Level: Determines whether to challenge a visitor based on their threat score, calculated from their IP reputation across Cloudflare services like WAF managed rules & DDoS along with Global Project Honeypot.
- Custom Rules: These are custom rules set up by Cloudways, including an enterprise bot manager, Under Attack mode, login protection, and integration with project honeypot among other rules specifically curated to secure your sites from diverse attacks.
- Managed Rules: Rules set up & managed by Cloudflare to shield against common internet attacks.
- HTTP DDoS: Mitigation of DDoS attacks triggered through HTTP requests, typically POST & GET.
- Browser Integrity Check: Verifies visitor legitimacy by examining their browser & other information.
- User Agent Blocking: Identifies malicious visitors such as bots, automated scripts, outdated & insecure browsers, and devices & software commonly associated with malicious activities based on browser, operating system, and other patterns.
- Validation: Cloudflare performs a validation check for every request. The Validation component executes prior to all other WAF features like custom rules or WAF Managed Rules. The validation check blocks malformed requests like Shellshock attacks and requests with certain attack patterns in their HTTP headers before any allowlist logic occurs.
3) Top Events by Source
Finally, the events by source section displays the top sources where the majority of security events originated. It lists the top 5 (up to 15) sources, showcasing details such as IP addresses, User Agents (OS, Browser, etc), paths (pages under attack), countries of origin (where malicious actors are located), Hosts, and HTTP methods being used.
The Cloudflare add-on was our attempt to bring Enterprise-level performance and security for SMBs.
While we may have accomplished this mission with the addition of edge page caching; we remain forever committed to improving the customer experience in any way possible.
Moving forward, we’re dedicated to continually improving this add-on for our diverse customer base. We’re actively listening to our customer feedback through interviews and social media channels seeking ways to enhance functionality and address user needs.
Feel free to share any suggestions on our feedback page & we’ll explore the possibility of implementing them.
I'm a Product Marketer with a strong passion for discovering cutting-edge tech solutions that address our everyday challenges. Delving into the world of innovative technology never ceases to amaze me. When I'm not immersed in the realm of tech, you can catch me scrolling through Instagram, admiring the vibrant beauty of various bird species, or escaping into the captivating world of fiction.